[swift-evolution] floating point numbers implicit conversion

[Xiaodi Wu]

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> 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
> 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/a964641f/attachment.html>