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 > <[email protected]> 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 > <[email protected] <mailto:[email protected]>> 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 > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
