Skip to content

Make the naming of underlying builtin for FP + Vector match Integer. #15430

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Mar 22, 2018

Conversation

stephentyrone
Copy link
Contributor

@stephentyrone stephentyrone commented Mar 22, 2018

For stdlib integer types, these are named _value and init(_ _value: Builtin.xxx). This patch adopts the same scheme for stdlib floating point and SDK overlay vector types, and removes a legacy init for integers that was only needed to support them. There should be no changes visible outside of the stdlib, and no functional change within the stdlib; the naming of some implementation details is simply more uniform now.

For stdlib integer types, these builtin wrapped by the Swift type is named _value and the init is (_ _value: Builtin.xxx). This patch adopts the same scheme for stdlib floating point and SDK overlay vector types, and removes a legacy init for integers that was only needed to support them. There should be no changes visible outside of the stdlib.
@stephentyrone stephentyrone requested a review from moiseev March 22, 2018 17:47
@stephentyrone
Copy link
Contributor Author

@swift-ci Please smoke test.

@stephentyrone stephentyrone merged commit 8e11af4 into swiftlang:master Mar 22, 2018
@stephentyrone stephentyrone deleted the stdlib_value_naming branch March 22, 2018 20:43
@slavapestov
Copy link
Contributor

@stephentyrone I'm going to revert this because it broke the source compat suite (not your fault, it's a constraint solver bug).

However what exposed the bug is the addition of new unlabeled initializers on numeric types. I think we want to avoid these because they make the type checker go exponential. Since builtin types are never public, we can change these initializers without breaking anyone.

Do you want to give them labels again on floats and integers?

slavapestov added a commit to slavapestov/swift that referenced this pull request Mar 23, 2018
@rudkx
Copy link
Contributor

rudkx commented Mar 23, 2018

As long as the initializers are not failable I don't think they're going to cause any problems. If all the overloads in an overload set return the same type we're able to split the constraint system which avoids the exponential behavior.

The problem we have with Int, Float, etc. is that around Swift 3.1 (?) timeframe we introduced unlabeled failable inits.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants