Proposal Accepted
After careful consideration of the thoughtful discussion during the review and pitch threads, the Core Team has decided to accept SE-0307.
The Core Team recognizes this was a divisive topic.
While the consensus of the review discussion recognized the friction caused by the duality of the CGFloat and Double types, there was healthy disagreement on the thread on what principles to apply to addressing this problem. Every bit of complexity we add to Swift has an implementation cost to the compiler and a cognitive cost to the user, and implicit conversions — even narrowly defined ones — are a form of magic in the language that can solve problems add nontrivial weight. Thus the Core Team took the feedback on the review thread very seriously, weighed the concerns, and tried to make a balanced decision based on the proposal's goals and the long-term implications.
A large amount of Swift's design, from the earliest days, has been influenced by a strategy of cohesive and effective platform integration. Swift's interoperability with Objective-C and C remains a keystone in its success as a language. That enabled developers to use Swift to meaningfully build software first for Apple platforms and later elsewhere while leveraging the existing APIs on those platforms. Unsurprisingly, the C and Objective-C "bridge" in the compiler (aka, the "ClangImporter") that translates C and Objective-C APIs into Swift APIs is full of both principled translation rules and heuristics tailored to the API patterns of Objective-C and specific types in the Apple SDK.
The Core Team believes the narrowly defined implicit type conversion, as described in SE-0307, addresses a long-standing impedance between Swift code and a platform type — CGFloat — whose inception long predates Swift. The Core Team feels that implicit conversions, as proposed in SE-0307, can be wielded sparingly to solve narrowly focused problems that arise from platform compatibility and interoperability. In this case, such a solution can be justified when the developer's cognitive load is a net positive by removing a significant point of friction when writing code for frequently used APIs. In this case, we can understand the implications of the implicit conversion on the compiler's performance. Finally, it solves an apparent standing problem for which alternative solutions cannot sufficiently address.
However, the Core Team still believes that generalizing support for implicit conversions would be harmful to the language. Implicit conversions, in general, would make code difficult to reason about and compromise the compiler's reliability and performance to infer types.
Thank you, everyone, who participated in the review.