[swift-evolution] floating point numbers implicit conversion

[David Waite]

Has it been proposed to eventually make CGFloat into a typealias for Double to reduce the amount of explicit conversion necessary? (I realize as a proposal this would be better suited for corelibs-libfoundation)

- For Apple platforms, eventually CGFloat will *always* be a Double value, as Swift does not have a 32-bit OS X runtime, and my understanding is that new builds are no longer accepted via the App Store for 32 bit IOS versions. I believe this would limit Apple platform impact to 32-bit iOS apps shipped outside the App Store which have upgraded to some future version of XCode.

- Within corelibs-libfoundation, I believe CGFloat is only used for CGPoint and NSAfflineTransform. How useful is it to have these be 32 bit on a 32 bit target, where they aren’t being defined as floats for compatibility?

-DW

> On Jun 16, 2017, at 10:19 AM, Xiaodi Wu via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Implicit promotion has been brought up on the list before, many times over many years. The scale and implications of the change not to be underestimated.
> 
> To give a taste of what would be involved, consider that new integer protocols were recently implemented that allow heterogeneous comparison; these have proved to be tricky to implement in a way that preserves user expectations in the context of integer literals. (I will write shortly with thoughts on revisiting certain specifics.)
> 
> Implicit promotion would be much more complicated. There is little point in discussing whether such a feature in the abstract is desirable or not. It would be necessary to have a detailed proposed design and evaluate whether the specific design is desirable, in light of its interactions with other parts of the system. For one, I think it’s important that no code that is currently legal produce a different result: this in itself is not trivial to achieve.
> 
> On Fri, Jun 16, 2017 at 11:08 Ted F.A. van Gaalen via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> Hello,
> 
> Appr. a year ago I suggested to allow implicit conversion between floating point number types,
> that is between Float, CGFloat  Double..Float80 … 
> (Note that CGFloat IS a Double on 64-bit systems btw),
> 
> E.g I am currently making things using SceneKit 3D, wich obviously involves a lot
> of floating point arithmetic, using functions from several libraries where
> some use Floats, others Double or CGFloat etc.. 
> That wouldn't be so bad, were it not that all the work that I do contains
> a lot of of unavoidable explicit Floating point conversions like so:
> 
> let ypos = CGFloat(1080.0 - (yGravity * yfactor))  // double in expression to CGFloat
> 
> camera1.reorientate (
>                     SCNVector3(x: Float(motionGravityY *  -0.08),
>                                y: Float(motionGravityX *  -0.1),
>                                z: roll )             )
> 
> This is tedious and makes source less readable.
> 
> With implicit floating point number conversion It could be like this
> 
> var float1,float2,float3: Float
> var double1,double2,double3: Double
> var cgfloat1, cgfloat2, ccgfloat3 CGFloat 
> 
> float1 = cgfloat2 * double3 + float1   // implicit conversion should be allowed (whereby everything 
> in the expression should be promoted to the highest precision var in the expression (Double here)  
> which then would be type wise:   
> Float = CGFloat(implicitly. promoted to Double) * Double) + Float  (imp. promoted to Double) 
> 
> Also, implicit conversion when passing function parameters would be very convenient as well e.g.
> 
> This function: 
>        func someMath(p1: Float, p2: Float, result: Inout Float) {…}
> 
> could then be called without explicit conversion like so:
> 
>         someMath(p1: double1, p2: cgfloat1,  result: &double3)   
> 
> // yes, also on inout parameters. This is done 2 times during the call and when returning.
>  
> 
> As I vaguely remember  there were objections to this implicit conversion of FP numbers,
> because this was (as viewed back then) too complicated to implement?
> 
> Note that people that regularly work with floating point numbers are
> well aware about having a precision loss when e.g.  when converting
> from Double to Float, or indeed between other numerical types as well 
> no problem.
> 
> For those not desiring such flexibility, there could be a new compiler option(s)
> that disallows this freedom of implicit floating point number conversion.
> 
> or have at least (suppressible) compiler warnings about precision loss,
> e.g when doing this: float = double.. 
> 
> ?
> 
> Kind Regards from Speyer, Germany
> TedvG
> 
> 
> 
> 
> 
> 
> 
> 
> 
>   
> 
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170616/9394f7d2/attachment.html>