Hi @xedin, what should I look at if I'm interested in fixing this but don't have familiarity with where this is handled or what the fix will look like? I'd like to figure out if I can do this before assigning it to myself.
@amritpan This might be a bit tricky actually due to how conversion restrictions behave. CGFloat/Double conversion needs to wait until all Optional-to-Optional conversions are performed for a particular location, and if the optionality is the same on both sides (e.g. both types are no longer optional) allow Double/CGFloat conversion (Related methods are `matchTypes` and `simplifyRestrictedConstraintImpl` located in CSSimplify.cpp). This is relatively straight-forward to implement and it would result in a valid solution (you can double-check that using `-Xfrontend -debug-constraints` - more info about that @ https://github.com/apple/swift/blob/main/docs/DebuggingTheCompiler.md#debugging-the-type-checker). Next step is to add a number of implicit `.map` calls based on the number of `optional-to-optional` conversions performed for a given location during solution application (related code lives in CSApply.cpp - `coerceToType` method, you can search for ConversionRestrictionKind::DoubleToCGFloat to find relevant location). Here is another catch though - `ConstraintRestrictions` are not positional, so there is no way (currently) to determine how many did each location (identified by a ConstraintLocator) have, you'd have to change that to be able to insert appropriate number of `.map` calls or somehow figure out what was the optionality before first optional-to-optional conversion has been applied to a given location.
@mattyoung No, that is different and also not a problem, as it works as expected. It is logically impossible to make typed pointers to two types with possibly distinct representations in memory become interchangeable with each other.