i’m strongly –1 on this proposal.
this is a major change to the semantics of the language, and the fact that it only applies to one pair of types doesn’t seem like a solid justification for characterizing it as a “narrowly-tailored” solution. if we break a fundamental assumption in the language, then that assumption is now broken, even if it was only broken once.
the real problem here, which doesn’t seem to have been mentioned in the Alternatives Considered section, is that we don’t have a floating point type with platform-defined width, the way Int and UInt are currently related to Int32, Int64, and UInt32, UInt64.
note that this is not the option 3 considered in the proposal, which is to have a platform-dependent typealias CGFloat pointing to either Float or Double. the correct long-term solution would be to introduce a word-sized Real type (or some other, more appropriate name) that requires an explicit conversion to a fixed-width floating point type, just as Int requires an explicit conversion to Int32 or Int64. we should then encourage relevant APIs to be encouraged to be written using the word-sized Real type instead of the fixed-width types, exactly the way integer types are treated right now.
i understand the ergonomic motivations of this proposal, but i want to highlight that, in the past, this was not considered adequate justification for this sort of change to the language. for example, the codepoint and character literals proposal i put forth last year was a solution proposed to solve what was essentially the same problem in a different context — type ergonomics for interop with a certain class of C APIs — with very similar implications for the language type system. despite the fact that that proposal was limited to the type checker/inferencer, with no changes to actual program behavior (unlike this proposal), the codepoint literals proposal was rejected because the community felt that type ergonomics for the purposes of interacting with a specific class of C APIs did not warrant the proposed changes to the language.
i do not feel that there is a meaningful difference between the C APIs that this proposal aims to make easier to use, and the ones that previously rejected proposals aimed to make easier to use, other than that the APIs in this situation are vended by Apple.