-
Notifications
You must be signed in to change notification settings - Fork 10.4k
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
[TypeChecker] Implement Double <-> CGFloat implicit conversion #34401
Conversation
@swift-ci please test source compatibility |
Debug build was a UPASS |
ee8542a
to
51aa211
Compare
This looks fantastic in terms of improving the usability of To the extent that it touches upon the Swift language itself, and in particular type relationships and one of the original tentpole design decisions not to have implicit numeric conversions, I hope we'll have a chance to discuss and review this through the Swift Evolution process. If presented as a sort of built-in ABI-stable retroactive |
Thanks, @xwu! At this point I'm mostly trying to figure out whether it's feasible and what the performance impact is going to be. This would definitely be pitched and discussed on Swift Evolution if this experiment is a success. |
@swift-ci please build toolchain macOS |
51aa211
to
c47feea
Compare
@swift-ci please build toolchain macOS |
macOS Toolchain Install command |
c47feea
to
2573c7d
Compare
@swift-ci please build toolchain |
Linux Toolchain (Ubuntu 16.04) Install command |
macOS Toolchain Install command |
2573c7d
to
bbfb1d9
Compare
@swift-ci please test source compatibility |
bbfb1d9
to
0d5de0e
Compare
@swift-ci please test source compatibility |
1 similar comment
@swift-ci please test source compatibility |
0fddd92
to
b54012d
Compare
@swift-ci please test source compatibility |
@swift-ci please build toolchain |
macOS Toolchain Install command |
b54012d
to
ad047cd
Compare
@swift-ci please test source compatibility |
a556030
to
ffc3e4f
Compare
This makes it possible to pick `CGFloat` function/operator overloads even in the presence of literals, otherwise non-default literal score gets in a way and solver ends up producing a lot more solutions with implicit Double<->CGFloat conversion than it can disambiguate, so it's better to just preserve the old behavior and pick `CGFloat` concrete overloads when appropriate.
… arguments If argument is a floating-point literal, with newly introduced implicit Double<->CGFloat conversion, sometimes it's better to choose a concrete function/operator overload on `CGFloat` even if it's not a default literal type e.g. `let _: CGFloat = min(1.0, log(<CGFloat value>))` shouldn't form solutions with `Double` arguments since it would result in multiple implicit conversions, it's better to use a `CGFloat` type for the arguments.
…ce of Double<->CGFloat conversion Not all of the unary operators have `CGFloat` overloads, so in order to preserve previous behavior (and overall best solution) with implicit Double<->CGFloat conversion we need to allow attempting generic operators for such cases. ```swift let _: CGFloat = -.pi / 2 ``` `-` doesn't have `CGFloat` overload (which might be an oversight), so in order to preserve type-checking behavior solver can't be allowed to pick `-(Double) -> Double` based on overload of `/`, the best possible solution would be with `/` as `(CGFloat, CGFloat) -> CGFloat` and `-` on a `FloatingPoint` protocol.
…urrently unsupported on Windows)
…al type This wasn't a problem before since locator wasn't really used by `ExprRewritter:coerceToType` but with Double<->CGFloat conversion it needs the locator to be anchored at a rewritten expression instead of the original one to form a correct implicit initializer call.
…s (argument or result)
…t conversions Change the conversion rule to favor any number of widenings (CGFloat -> Double) over even a single narrowing conversion and if there is no way to avoid narrowing (due to contextual requirements) attempt it as late as possible (the deeper in the AST that conversion is located the higher its score). This is a generally better rule when it comes to rounding and information loss that would result from narrowing conversions.
… narrowing conversions (Double -> CGFloat)
…onversion Doing so resulted in performance impact due to the number of partial solutions increase.
Just like generic overloads, `shrink` should always avoid any solutions with implicit conversions. Reducing disjunction domains becaused on solutions with implicit conversions could have negative performance impact due to the increase in total number of solutions that have to be examined as a result.
52607fb
to
0e6198d
Compare
@swift-ci please test source compatibility |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm excited about this! Just some nits...
Thanks Xiaodi Wu!
@swift-ci please test source compatibility |
@swift-ci please test |
Windows failure:
|
@swift-ci please test source compatibility release |
Release suite failed with |
Build failed |
Build failed |
Implement an implicit conversion between
Double
andCGFloat
types viaan implicit initializer call.
Resolves: rdar://problem/70592377