# floating point numbers implicit conversion

**URL:** <https://forums.swift.org/t/floating-point-numbers-implicit-conversion/6129>\
**Category:** Discussion\
**Created:** [June 15, 2017, 9:49pm UTC](https://forums.swift.org/t/floating-point-numbers-implicit-conversion/6129 "2017-06-15T21:49:26Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![TedvG](https://avatars.discourse-cdn.com/v4/letter/t/df788c/32.png) [@TedvG](https://forums.swift.org/u/TedvG)\
**Post date:** [June 15, 2017, 9:49pm UTC](https://forums.swift.org/t/floating-point-numbers-implicit-conversion/6129/1 "2017-06-15T21:49:26Z")

</div>

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 (  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;SCNVector3(x: Float(motionGravityY \* -0.08),  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;y: Float(motionGravityX \* -0.1),  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;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:  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;func someMath(p1: Float, p2: Float, result: Inout Float) {…}

could then be called without explicit conversion like so:

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;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

---

<div class="post-metadata">

**Author:** ![xwu](https://avatars.discourse-cdn.com/v4/letter/x/b487fb/32.png) [@xwu](https://forums.swift.org/u/xwu)\
**Post date:** [June 16, 2017, 4:19pm UTC](https://forums.swift.org/t/floating-point-numbers-implicit-conversion/6129/2 "2017-06-16T16:19:16Z")

</div>

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@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 (  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;SCNVector3(x: Float(motionGravityY \* -0.08),  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;y: Float(motionGravityX \* -0.1),  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;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:  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;func someMath(p1: Float, p2: Float, result: Inout Float) {…}
> > 
> > could then be called without explicit conversion like so:
> > 
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;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@swift.org  
> > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)

---

<div class="post-metadata">

**Author:** ![dwaite](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/dwaite/32/1200_2.png) [@dwaite](https://forums.swift.org/u/dwaite)\
**Post date:** [June 16, 2017, 5:35pm UTC](https://forums.swift.org/t/floating-point-numbers-implicit-conversion/6129/3 "2017-06-16T17:35:36Z")

</div>

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@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@swift.org \<mailto:swift-evolution@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 (  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;SCNVector3(x: Float(motionGravityY \* -0.08),  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;y: Float(motionGravityX \* -0.1),  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;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:  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;func someMath(p1: Float, p2: Float, result: Inout Float) {…}
> > 
> > could then be called without explicit conversion like so:
> > 
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;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@swift.org \<mailto:swift-evolution@swift.org\>  
> > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)  
> > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > swift-evolution mailing list  
> > swift-evolution@swift.org  
> > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)

---

<div class="post-metadata">

**Author:** ![gparker42](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/gparker42/32/373_2.png) [@gparker42](https://forums.swift.org/u/gparker42)\
**Post date:** [June 16, 2017, 10:34pm UTC](https://forums.swift.org/t/floating-point-numbers-implicit-conversion/6129/4 "2017-06-16T22:34:46Z")

</div>

watchOS is still 32-bit. That makes "eventually" be longer that you would like, I think.

> **···**
>
> > On Jun 16, 2017, at 10:35 AM, David Waite via swift-evolution \<swift-evolution@swift.org\> wrote:
> > 
> > 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.
> 
> --  
> Greg Parker gparker@apple.com \<mailto:gparker@apple.com\> Runtime Wrangler

---

<div class="post-metadata">

**Author:** ![dwaite](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/dwaite/32/1200_2.png) [@dwaite](https://forums.swift.org/u/dwaite)\
**Post date:** [June 16, 2017, 10:38pm UTC](https://forums.swift.org/t/floating-point-numbers-implicit-conversion/6129/5 "2017-06-16T22:38:09Z")

</div>

Meh, thats a pretty long eventually. Thanks for shooting it down gently ;-)

-DW

> **···**
>
> > On Jun 16, 2017, at 4:34 PM, Greg Parker \<gparker@apple.com \<mailto:gparker@apple.com\>\> wrote:
> > 
> > > On Jun 16, 2017, at 10:35 AM, David Waite via swift-evolution \<swift-evolution@swift.org \<mailto:swift-evolution@swift.org\>\> wrote:
> > > 
> > > 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.
> > 
> > watchOS is still 32-bit. That makes "eventually" be longer that you would like, I think.

---

<div class="post-metadata">

**Author:** ![TedvG](https://avatars.discourse-cdn.com/v4/letter/t/df788c/32.png) [@TedvG](https://forums.swift.org/u/TedvG)\
**Post date:** [June 17, 2017, 8:21pm UTC](https://forums.swift.org/t/floating-point-numbers-implicit-conversion/6129/6 "2017-06-17T20:21:50Z")

</div>

Hi Xiaodi

in 1966-1970 PL/I, a static-typed procedural block-structured programming language  
far ahead of its time, with the purpose of giving "all things to all programmers”  
was introduced by IBM as their main (mainframe) programming flagship.

I’ve worked with PL/I very often during my life. It is truly general purpose and has tons  
of features and is because of that quite overwhelming for starters like me in 1976 after  
Fortran as my first PL. PL/I is a bit like riding a gigantic powerful motor cycle without  
much instruction from the start and without training wheels back then of course.  
Took some time to master PL/I (no screens let alone IDEs back then), however, with  
the great reward to be in control of one of the most powerful PLs on the planet.

You might ask, what’s the context of this somewhat nostalgic emission: :o)

PL/I also has many data types like Binary, Bit, Character Complex, Decimal  
Fixed, Float,Picture etc. of various lengths and storage  
.  
Implicit data type conversion (coercion) between almost all PL/I data types has  
been available in PL/I right from the start. No problem - that is if you know what you are doing.  
What exactly to expect from conversions in PL/I is always predictable, also  
because it is described in detail in the programming manuals.  
Furthermore PL/I diagnostics and warnings are excellent.

So, implicit data type conversion (coercion) has been successfully implemented and used in an  
already complex programming language (in some cases far more advanced as Swift - apart from  
OOP) almost 40 years ago…  
It is now 2017 and you’re telling me that coercion is too difficult to implement in Swift ??

> 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.

It should be not so difficult I think… as it simply replaces  
explicit casts and the compiler can detect implicit conversions easily;  
be it in assignments, with expression operands or as call parameters.

> 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.)

Yes, can’t react on this need more information, I don’t see this in context of “user expectations” either.

btw, I was merely discussing Floating Point conversion \<=\> Integers?

> Implicit promotion would be much more complicated.

Why do you think so?  
float = double // compiler inferred type conversion, what’s so difficult about this assignment?  
Currently you’d have to use  
float = Float(double) // and you’re doing (explicitly) exactly the same thing.

> There is little point in discussing whether such a feature in the abstract is desirable or not.

Abstract? I don’t think so and have described this subject fairly concrete,  
illustrated with some examples.  
To me and certainly also many others this feature is desirable.  
As your say yourself  
“it has been brought forward so many times”  
Obviously many desire this feature and find this important.

> 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.

after gathering more insight, yes.

> 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.

As you know, Swift currently does not facilitate implicit conversion (coercion),  
which implies that current code (which of course does not contain implicit conversions)  
will function exactly as it does now, when it was compiled in a Swift version in which  
implicit conversion were implemented.

Kind Regards,  
TedvG  
[www.tedvg.com](http://www.tedvg.com)

> **···**
>
> > On 16. Jun 2017, at 18:19, Xiaodi Wu \<xiaodi.wu@gmail.com\> wrote:
> 
> > On Fri, Jun 16, 2017 at 11:08 Ted F.A. van Gaalen via swift-evolution \<swift-evolution@swift.org \<mailto:swift-evolution@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 (  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;SCNVector3(x: Float(motionGravityY \* -0.08),  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;y: Float(motionGravityX \* -0.1),  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;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:  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;func someMath(p1: Float, p2: Float, result: Inout Float) {…}
> > 
> > could then be called without explicit conversion like so:
> > 
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;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@swift.org \<mailto:swift-evolution@swift.org\>  
> > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)

---

<div class="post-metadata">

**Author:** ![xwu](https://avatars.discourse-cdn.com/v4/letter/x/b487fb/32.png) [@xwu](https://forums.swift.org/u/xwu)\
**Post date:** [June 17, 2017, 11:16pm UTC](https://forums.swift.org/t/floating-point-numbers-implicit-conversion/6129/7 "2017-06-17T23:16:05Z")

</div>

> Hi Xiaodi
> 
> in 1966-1970 PL/I, a static-typed procedural block-structured programming  
> language  
> far ahead of its time, with the purpose of giving "all things to all  
> programmers”  
> was introduced by IBM as their main (mainframe) programming flagship.
> 
> I’ve worked with PL/I very often during my life. It is truly general  
> purpose and has tons  
> of features and is because of that quite overwhelming for starters like me  
> in 1976 after  
> Fortran as my first PL. PL/I is a bit like riding a gigantic powerful  
> motor cycle without  
> much instruction from the start and without training wheels back then of  
> course.  
> Took some time to master PL/I (no screens let alone IDEs back then),  
> however, with  
> the great reward to be in control of one of the most powerful PLs on the  
> planet.
> 
> You might ask, what’s the context of this somewhat nostalgic emission:  
> :o)
> 
> PL/I also has many data types like Binary, Bit, Character Complex, Decimal  
> Fixed, Float,Picture etc. of various lengths and storage  
> .  
> Implicit data type conversion (coercion) between almost all PL/I data  
> types has  
> been available in PL/I right from the start. No problem - that is if you  
> know what you are doing.  
> What exactly to expect from conversions in PL/I is always predictable, also  
> because it is described in detail in the programming manuals.  
> Furthermore PL/I diagnostics and warnings are excellent.
> 
> So, implicit data type conversion (coercion) has been successfully  
> implemented and used in an  
> already complex programming language (in some cases far more advanced as  
> Swift - apart from  
> OOP) almost 40 years ago…  
> It is now 2017 and you’re telling me that coercion is too difficult to  
> implement in Swift ??
> 
> 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.
> 
> It should be not so difficult I think… as it simply replaces  
> explicit casts and the compiler can detect implicit conversions easily;  
> be it in assignments, with expression operands or as call parameters.
> 
> 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.)
> 
> Yes, can’t react on this need more information, I don’t see this in  
> context of “user expectations” either.
> 
> btw, I was merely discussing Floating Point conversion \<=\> Integers?
> 
> Implicit promotion would be much more complicated.
> 
> Why do you think so?  
> float = double // compiler inferred type conversion, what’s so difficult  
> about this assignment?  
> Currently you’d have to use  
> float = Float(double) // and you’re doing (explicitly) exactly the same  
> thing.
> 
> There is little point in discussing whether such a feature in the abstract  
> is desirable or not.
> 
> Abstract? I don’t think so and have described this subject fairly  
> concrete,  
> illustrated with some examples.  
> To me and certainly also many others this feature is desirable.  
> As your say yourself  
> “it has been brought forward so many times”  
> Obviously many desire this feature and find this important.

Ted, you'll find no disagreement from me that this feature is desirable.  
Now, having agreed on that, how do you intend to design and implement it?  
How would you expand the type system to accommodate these rules? How would  
you formalize the revised rules for type inference? What new protocols  
would you add that allow non-builtin types to participate? What existing  
code would break, and how would you migrate it? There's no way to proceed  
with the conversation until someone proposes a design.

> 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.
> 
> after gathering more insight, yes.
> 
> 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.
> 
> As you know, Swift currently does not facilitate implicit conversion  
> (coercion),  
> which implies that current code (which of course does not contain implicit  
> conversions)  
> will function exactly as it does now,

That is not implied. Swift has type inference, which means that, with the  
implementation of implicit promotion, the inferred type of certain  
expressions that are legal today will change. For instance, integer  
literals have no type of their own and are inferred to be of some type or  
another based on context. When combined with bitwise operators, the  
presence or absence of overloads that allow heterogeneous operations can  
change the result of code that compiles both before and after the  
implementation of the feature. This is just one example of why implicit  
integer promotion in a strictly typed language with type inference and  
without certain generics features is very hard.

when it was compiled in a Swift version in which

> **···**
>
> On Sat, Jun 17, 2017 at 3:21 PM, Ted F.A. van Gaalen \<tedvgiosdev@gmail.com\> wrote:
> 
> > On 16. Jun 2017, at 18:19, Xiaodi Wu \<xiaodi.wu@gmail.com\> wrote:  
> > implicit conversion were implemented.
> > 
> > Kind Regards,  
> > TedvG  
> > [www.tedvg.com](http://www.tedvg.com)

---

<div class="post-metadata">

**Author:** ![David\_Sweeris](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/david_sweeris/32/31302_2.png) [@David\_Sweeris](https://forums.swift.org/u/David_Sweeris)\
**Post date:** [June 18, 2017, 3:39am UTC](https://forums.swift.org/t/floating-point-numbers-implicit-conversion/6129/8 "2017-06-18T03:39:28Z")

</div>

I'm not sure which generic features you're referring to. Would you (or anyone else who knows) mind elaborating?

- Dave Sweeris

> **···**
>
> > On Jun 17, 2017, at 16:16, Xiaodi Wu via swift-evolution \<swift-evolution@swift.org\> wrote:
> > 
> > > On Sat, Jun 17, 2017 at 3:21 PM, Ted F.A. van Gaalen \<tedvgiosdev@gmail.com\> wrote:
> > > 
> > > As you know, Swift currently does not facilitate implicit conversion (coercion),  
> > > which implies that current code (which of course does not contain implicit conversions)  
> > > will function exactly as it does now,
> > 
> > That is not implied. Swift has type inference, which means that, with the implementation of implicit promotion, the inferred type of certain expressions that are legal today will change. For instance, integer literals have no type of their own and are inferred to be of some type or another based on context. When combined with bitwise operators, the presence or absence of overloads that allow heterogeneous operations can change the result of code that compiles both before and after the implementation of the feature. This is just one example of why implicit integer promotion in a strictly typed language with type inference and without certain generics features is very hard.

---

<div class="post-metadata">

**Author:** ![xwu](https://avatars.discourse-cdn.com/v4/letter/x/b487fb/32.png) [@xwu](https://forums.swift.org/u/xwu)\
**Post date:** [June 18, 2017, 3:43am UTC](https://forums.swift.org/t/floating-point-numbers-implicit-conversion/6129/9 "2017-06-18T03:43:53Z")

</div>

In Swift, all types and all operators are implemented in the standard  
library. How do you express the idea that, when you add values of disparate  
types T and U, the result should be of the type with greater precision? You  
need to be able to spell this somehow.

> **···**
>
> On Sat, Jun 17, 2017 at 22:39 David Sweeris \<davesweeris@mac.com\> wrote:
> 
> > On Jun 17, 2017, at 16:16, Xiaodi Wu via swift-evolution \< \> swift-evolution@swift.org\> wrote:
> > 
> > On Sat, Jun 17, 2017 at 3:21 PM, Ted F.A. van Gaalen \< \> tedvgiosdev@gmail.com\> wrote:
> > 
> > As you know, Swift currently does not facilitate implicit conversion
> > 
> > > (coercion),  
> > > which implies that current code (which of course does not contain  
> > > implicit conversions)  
> > > will function exactly as it does now,
> > 
> > That is not implied. Swift has type inference, which means that, with the  
> > implementation of implicit promotion, the inferred type of certain  
> > expressions that are legal today will change. For instance, integer  
> > literals have no type of their own and are inferred to be of some type or  
> > another based on context. When combined with bitwise operators, the  
> > presence or absence of overloads that allow heterogeneous operations can  
> > change the result of code that compiles both before and after the  
> > implementation of the feature. This is just one example of why implicit  
> > integer promotion in a strictly typed language with type inference and  
> > without certain generics features is very hard.
> > 
> > I'm not sure which generic features you're referring to. Would you (or  
> > anyone else who knows) mind elaborating?
> > 
> > - Dave Sweeris

---

<div class="post-metadata">

**Author:** ![David\_Sweeris](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/david_sweeris/32/31302_2.png) [@David\_Sweeris](https://forums.swift.org/u/David_Sweeris)\
**Post date:** [June 18, 2017, 4:01am UTC](https://forums.swift.org/t/floating-point-numbers-implicit-conversion/6129/10 "2017-06-18T04:01:31Z")

</div>

Oh, ok... I thought you meant "conditional conformance" or something concrete :-D

Off the top of my head, with "literals as generic parameters",  
protocol Addable {  
&nbsp;&nbsp;associatedtype BitsOfPrecision: IntegerLiteral  
&nbsp;&nbsp;static func + \<T: Addable\> (\_: Self, \_: T) -\> T where T.BitsOfPrecision \>  
BitsOfPrecision  
&nbsp;&nbsp;static func + \<T: Addable\> (\_: Self, \_: T) -\> Self where T.BitsOfPrecision \<= BitsOfPrecision  
}

Although, come to think of it, I suppose that's a bit more than simply using literals as types. Still, it's all information that's available at compile time, though.

- Dave Sweeris

> **···**
>
> > On Jun 17, 2017, at 20:43, Xiaodi Wu \<xiaodi.wu@gmail.com\> wrote:
> > 
> > In Swift, all types and all operators are implemented in the standard library. How do you express the idea that, when you add values of disparate types T and U, the result should be of the type with greater precision? You need to be able to spell this somehow.

---

<div class="post-metadata">

**Author:** ![Brent\_Royal-Gordon](https://avatars.discourse-cdn.com/v4/letter/b/53a042/32.png) [@Brent\_Royal-Gordon](https://forums.swift.org/u/Brent_Royal-Gordon)\
**Post date:** [June 18, 2017, 5:02am UTC](https://forums.swift.org/t/floating-point-numbers-implicit-conversion/6129/11 "2017-06-18T05:02:45Z")

</div>

To be slightly less coy: You need to be able to say that one value type is a subtype of another. Then you can say Int8 is a subtype of Int16, and the compiler knows that it can convert any Int8 to an Int16 but not vice versa. This adds lots of complexity and makes parts of the compiler that are currently far too slow even slower, but it's not difficult to imagine, just difficult to practically implement given the current state of the Swift compiler.

> **···**
>
> > On Jun 17, 2017, at 8:43 PM, Xiaodi Wu via swift-evolution \<swift-evolution@swift.org\> wrote:
> > 
> > How do you express the idea that, when you add values of disparate types T and U, the result should be of the type with greater precision? You need to be able to spell this somehow.
> 
> --  
> Brent Royal-Gordon  
> Architechies

---

<div class="post-metadata">

**Author:** ![xwu](https://avatars.discourse-cdn.com/v4/letter/x/b487fb/32.png) [@xwu](https://forums.swift.org/u/xwu)\
**Post date:** [June 18, 2017, 4:18am UTC](https://forums.swift.org/t/floating-point-numbers-implicit-conversion/6129/12 "2017-06-18T04:18:46Z")

</div>

And, without integer literals as generic parameters, how would you express  
this operation?

> **···**
>
> On Sat, Jun 17, 2017 at 23:01 David Sweeris \<davesweeris@mac.com\> wrote:
> 
> > On Jun 17, 2017, at 20:43, Xiaodi Wu \<xiaodi.wu@gmail.com\> wrote:
> > 
> > In Swift, all types and all operators are implemented in the standard  
> > library. How do you express the idea that, when you add values of disparate  
> > types T and U, the result should be of the type with greater precision? You  
> > need to be able to spell this somehow.
> > 
> > Oh, ok... I thought you meant "conditional conformance" or something  
> > \*concrete\* :-D
> > 
> > Off the top of my head, with "literals as generic parameters",  
> > protocol Addable {  
> > &nbsp;&nbsp;associatedtype BitsOfPrecision: IntegerLiteral  
> > &nbsp;&nbsp;static func + \<T: Addable\> (\_: Self, \_: T) -\> T where T.BitsOfPrecision  
> > \>  
> > BitsOfPrecision  
> > &nbsp;&nbsp;static func + \<T: Addable\> (\_: Self, \_: T) -\> Self where  
> > T.BitsOfPrecision \<= BitsOfPrecision  
> > }
> > 
> > Although, come to think of it, I suppose that's a bit more than simply  
> > using literals as types. Still, it's all information that's available at  
> > compile time, though.
> > 
> > - Dave Sweeris

---

<div class="post-metadata">

**Author:** ![xwu](https://avatars.discourse-cdn.com/v4/letter/x/b487fb/32.png) [@xwu](https://forums.swift.org/u/xwu)\
**Post date:** [June 18, 2017, 6:04am UTC](https://forums.swift.org/t/floating-point-numbers-implicit-conversion/6129/13 "2017-06-18T06:04:54Z")

</div>

> How do you express the idea that, when you add values of disparate types T  
> and U, the result should be of the type with greater precision? You need to  
> be able to spell this somehow.
> 
> To be slightly less coy:

:)

You need to be able to say that one value type is a subtype of another.

> Then you can say Int8 is a subtype of Int16, and the compiler knows that it  
> can convert any Int8 to an Int16 but not vice versa. This adds lots of  
> complexity and makes parts of the compiler that are currently far too slow  
> even slower, but it's not difficult to imagine, just difficult to  
> practically implement given the current state of the Swift compiler.

And then there are follow-on issues. As but a single example, consider  
integer literals, which are of course commonly used with these operations.  
Take the following statements:

var x = 42 as UInt32  
let y = x + 2

What is the inferred type of 2? Currently, that would be UInt32. What is  
the inferred type of y? That would also be UInt32. So, it's tempting to  
say, let's keep this rule that integer literals are inferred to be of the  
same type. But now:

let z = x + (-2)

What is the inferred type of -2? If it's UInt32, then this expression is a  
compile-time error and we've ruled out integer promotion for a common use  
case. If OTOH it's the default IntegerLiteralType (Int), what is the type  
of z? It would have to be Int.

Now suppose x were instead of type UInt64. What would be the type of z, if  
-2 is inferred to be of type Int? The answer would have to be  
DoubleWidth\<Int64\>. That is clearly overkill for subtracting 2. So let's  
say instead that the literal is inferred to be of the smallest type that  
can represent the value (i.e. Int8). If so, then what is the result of this  
computation?

let a = x / ~0

Currently, in Swift 3, ~0 is equal to UInt32.max. But if we have a rule  
that the literal should be inferred to be the smallest type that can  
represent the value, then the result of this computation \_changes\_. That  
won't do. So let's say instead that the literal is inferred to be of the  
same type as the other operand, unless it is not representable as such, in  
which case it is then of the smallest type that can represent the value.  
Firstly, and critically, this is not very easy to reason about. Secondly,  
it still does not solve another problem with the smallest-type rule.  
Consider this example:

let b = x / -64

If I import a library that exposes Int7 (the standard library itself has an  
internal Int63 type and, I think, other Int{2\*\*n - 1} types as well), then  
the type of b would change!

Of all the alternatives here, it would seem that disallowing integer  
promotion with literals is after all the most straightforward answer.  
However, it is not a satisfying one.

My point here, at this point, is not to drive at a consensus answer for  
this particular issue, but to point out that what we are discussing is  
essentially a major change to the type system. As such, and because Swift  
already has so many rich features, \_numerous\_ such questions will arise  
about how any such change interacts with other parts of the type system.  
For these questions, sometimes there is not an "obvious" solution, and  
there is no guarantee that there will even be a single fully satisfying  
solution even after full consideration. That makes this a \_very\_ difficult  
topic, very difficult indeed.

To evaluate whether any such undertaking is a good idea, we would need to  
discuss a fully thought-out design and consider very carefully how it  
changes all the other moving parts of the type system; it is not enough to  
say merely that the feature is a good one.

> **···**
>
> On Sun, Jun 18, 2017 at 00:02 Brent Royal-Gordon \<brent@architechies.com\> wrote:
> 
> > On Jun 17, 2017, at 8:43 PM, Xiaodi Wu via swift-evolution \< \> swift-evolution@swift.org\> wrote:

---

<div class="post-metadata">

**Author:** ![David\_Sweeris](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/david_sweeris/32/31302_2.png) [@David\_Sweeris](https://forums.swift.org/u/David_Sweeris)\
**Post date:** [June 18, 2017, 5:11am UTC](https://forums.swift.org/t/floating-point-numbers-implicit-conversion/6129/14 "2017-06-18T05:11:41Z")

</div>

Off the top of my head? As the language stands now, maybe a ton of extensions so that it never actually hits the fully generic version?

extension Addable where Self == Int8 {...}  
extension Addable where Self == Int16 {...}  
extension Addable where Self == Int32 {  
&nbsp;&nbsp;static func + \<T: Addable\> (lhs: Self, rhs: Int8) -\> Self {...}  
&nbsp;&nbsp;static func + \<T: Addable\> (lhs: Self, rhs: Int16) -\> Self {...}  
&nbsp;&nbsp;static func + \<T: Addable\> (lhs: Self, rhs: Int32) -\> Self {...}  
&nbsp;&nbsp;static func + \<T: Addable\> (lhs: Self, rhs: Int64) -\> Int64 {...}  
}  
extension Addable where Self == Int64 {...}

Dunno if that'll compile... it might need an `_IntNNType` protocol for each integer type so that the where clause could be "where Self: \_Int32Type" instead of "where Self == Int32" (of course, if such a thing were actually done, the obvious next step would be to make `UInt64` conform to `_Int8Type`, and see just how close you can get to wat [https://www.destroyallsoftware.com/talks/wat\](https://www.destroyallsoftware.com/talks/wat%5C)).

Even if that works, though, it'll all come crashing down as soon as someone makes an `Int128`... oh, nuts! I forgot about `DoubleWidth`!

Yeah, I don't think I can just pull that particular implementation out of the air.

- Dave Sweeris

> **···**
>
> > On Jun 17, 2017, at 21:18, Xiaodi Wu \<xiaodi.wu@gmail.com\> wrote:
> > 
> > And, without integer literals as generic parameters, how would you express this operation?
> > 
> > > On Sat, Jun 17, 2017 at 23:01 David Sweeris \<davesweeris@mac.com\> wrote:
> > > 
> > > > On Jun 17, 2017, at 20:43, Xiaodi Wu \<xiaodi.wu@gmail.com\> wrote:
> > > > 
> > > > In Swift, all types and all operators are implemented in the standard library. How do you express the idea that, when you add values of disparate types T and U, the result should be of the type with greater precision? You need to be able to spell this somehow.
> > > 
> > > Oh, ok... I thought you meant "conditional conformance" or something concrete :-D
> > > 
> > > Off the top of my head, with "literals as generic parameters",  
> > > protocol Addable {  
> > > &nbsp;&nbsp;associatedtype BitsOfPrecision: IntegerLiteral  
> > > &nbsp;&nbsp;static func + \<T: Addable\> (\_: Self, \_: T) -\> T where T.BitsOfPrecision \>  
> > > BitsOfPrecision  
> > > &nbsp;&nbsp;static func + \<T: Addable\> (\_: Self, \_: T) -\> Self where T.BitsOfPrecision \<= BitsOfPrecision  
> > > }
> > > 
> > > Although, come to think of it, I suppose that's a bit more than simply using literals as types. Still, it's all information that's available at compile time, though.
> > > 
> > > - Dave Sweeris

---

<div class="post-metadata">

**Author:** ![TedvG](https://avatars.discourse-cdn.com/v4/letter/t/df788c/32.png) [@TedvG](https://forums.swift.org/u/TedvG)\
**Post date:** [June 19, 2017, 3:46pm UTC](https://forums.swift.org/t/floating-point-numbers-implicit-conversion/6129/15 "2017-06-19T15:46:40Z")

</div>

> > How do you express the idea that, when you add values of disparate types T and U, the result should be of the type with greater precision? You need to be able to spell this somehow.
> 
> To be slightly less coy:
> 
> :)

what if one would allow all numeric conversions,  
also to those with smaller storage, and from signed to unsigned,  
(Of course with clear compiler warnings)  
but trap (throwable) conversion errors at runtime?  
Runtime errors would then be things like:  
-assigning a negative value to an unsigned integer  
-assigning a too large integer to an integer e.g UInt8 = 43234  
E.g. doing this:

let n1 = 255 // inferred Int  
var u1:UInt8  
u1 = n1 //this would be OK because: 0 \<=n1 \<= 255  
(currently this is not possible in Swift: "cannot assign value of type ‘Int’ to type ‘UInt8’)

Personally, I’d prefer that this should be allowed and cause a runtime error when conversion is not possible.  
Compile time warning could be “Warning: Overflow might occur when assigning value from type ‘Int’ to type ‘UInt8’”  
Same for floats if out of magnitude.

Then this would not be necessary:

> You need to be able to say that one value type is a subtype of another. Then you can say Int8 is a subtype of Int16, and the compiler knows that it can convert any Int8 to an Int16 but not vice versa. This adds lots of complexity and makes parts of the compiler that are currently far too slow even slower, but it's not difficult to imagine, just difficult to practically implement given the current state of the Swift compiler.
> 
> And then there are follow-on issues. As but a single example, consider integer literals, which are of course commonly used with these operations. Take the following statements:
> 
> var x = 42 as UInt32  
> let y = x + 2
> 
> What is the inferred type of 2? Currently, that would be UInt32. What is the inferred type of y? That would also be UInt32. So, it's tempting to say, let's keep this rule that integer literals are inferred to be of the same type. But now:
> 
> let z = x + (-2)
> 
> What is the inferred type of -2? If it's UInt32, then this expression is a compile-time error and we've ruled out integer promotion for a common use case. If OTOH it's the default IntegerLiteralType (Int), what is the type of z? It would have to be Int.

One of the things imho which I would change in Swift:  
I’d prefer this rule:  
\*\*\* within the scope of an expression, individual operands (vars and literals)  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;should all implicitly be promoted to lowest possible precision  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;with which the complete expression can be evaluated \*\*\*  
ergo:  
the smallest-type rule as it is now should be replaced by the above rule  
or in other words  
&nbsp;&nbsp;the smallest type possible within the scope of the complete expression.

Your above example would then not result in a compilation error. (currently it does)

in your example, with this rule, x would be implicitly promoted to Int  
and the result \*z\* would be an inferred Int.

another example of wat could be an allowable expression:

var result: Float = 0.0  
result = float \* integer \* uint8 + double  
// here, all operands should be implicitly promoted to Double before the complete expression evaluation.

//the evaluation of the expression results in a Double, which then is converted to a float during assignment to “result”

To summarise: Allow implicit conversions, but trap impossible things at runtime,  
unless of course the compiler can already figure out that it doesn’t work e.g in some cases with literals:  
let n1 = 234543  
var u1:UInt8 = n1 // overflow error

> Now suppose x were instead of type UInt64. What would be the type of z, if -2 is inferred to be of type Int? The answer would have to be DoubleWidth\<Int64\>. That is clearly overkill for subtracting 2. So let's say instead that the literal is inferred to be of the smallest type that can represent the value (i.e. Int8). If so, then what is the result of this computation?
> 
> let a = x / ~0
> 
> Currently, in Swift 3, ~0 is equal to UInt32.max. But if we have a rule that the literal should be inferred to be the smallest type that can represent the value, then the result of this computation \_changes\_. That won't do. So let's say instead that the literal is inferred to be of the same type as the other operand, unless it is not representable as such, in which case it is then of the smallest type that can represent the value. Firstly, and critically, this is not very easy to reason about. Secondly, it still does not solve another problem with the smallest-type rule. Consider this example:
> 
> let b = x / -64
> 
> If I import a library that exposes Int7 (the standard library itself has an internal Int63 type and, I think, other Int{2\*\*n - 1} types as well), then the type of b would change!
> 
> Of all the alternatives here, it would seem that disallowing integer promotion with literals is after all the most straightforward answer. However, it is not a satisfying one.

As written, I think that the other (better?) option is catching conversion errors at runtime,  
… this would require programmers having some common sense and awareness of what they’re doing :o)

> My point here, at this point, is not to drive at a consensus answer for this particular issue, but to point out that what we are discussing is essentially a major change to the type system. As such, and because Swift already has so many rich features, \_numerous\_ such questions will arise about how any such change interacts with other parts of the type system. For these questions, sometimes there is not an "obvious" solution, and there is no guarantee that there will even be a single fully satisfying solution even after full consideration. That makes this a \_very\_ difficult topic, very difficult indeed.

Yes, agree, it is. It is one of the difficulties of a static typed language (but a static type pre-compiled language is -whether I like it or not - currently still the best option for fast apps) in a static typed (OOP) language you need generics and protocols, but if going too far with these, one might paint him/herself into a corner, as increasingly more features become interdependent.. Looks like this could become problematic in further improving Swift. Also decisions of what are possible improvements and what not.

> To evaluate whether any such undertaking is a good idea, we would need to discuss a fully thought-out design and consider very carefully how it changes all the other moving parts of the type system; it is not enough to say merely that the feature is a good one.

thanks  
TedvG

> **···**
>
> > On 18. Jun 2017, at 08:04, Xiaodi Wu \<xiaodi.wu@gmail.com\> wrote:  
> > On Sun, Jun 18, 2017 at 00:02 Brent Royal-Gordon \<brent@architechies.com \<mailto:brent@architechies.com\>\> wrote:
> > 
> > > On Jun 17, 2017, at 8:43 PM, Xiaodi Wu via swift-evolution \<swift-evolution@swift.org \<mailto:swift-evolution@swift.org\>\> wrote:

---

<div class="post-metadata">

**Author:** ![Stephen\_Canon](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/stephen_canon/32/7220_2.png) [@Stephen\_Canon](https://forums.swift.org/u/Stephen_Canon)\
**Post date:** [June 19, 2017, 5:58pm UTC](https://forums.swift.org/t/floating-point-numbers-implicit-conversion/6129/16 "2017-06-19T17:58:28Z")

</div>

You would have this produce different results than:

&nbsp;&nbsp;let temp = float \* integer \* uint8  
&nbsp;&nbsp;result = temp + double

That would be extremely surprising to many unsuspecting users.

Don’t get me wrong; I \*really want\* implicit promotions (I proposed one scheme for them way back when Swift was first unveiled publicly). But there’s a lot more subtlety around them than it seems (for example the C and C++ implicit promotion rules can easily be described on a half-sheet of paper, but are the source of \*innumerable\* bugs). I would rather have no implicit promotions than half-baked implicit promotions.

– Steve

> **···**
>
> > On Jun 19, 2017, at 11:46 AM, Ted F.A. van Gaalen via swift-evolution \<swift-evolution@swift.org\> wrote:
> > 
> > var result: Float = 0.0  
> > result = float \* integer \* uint8 + double  
> > // here, all operands should be implicitly promoted to Double before the complete expression evaluation.

---

<div class="post-metadata">

**Author:** ![David\_Sweeris](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/david_sweeris/32/31302_2.png) [@David\_Sweeris](https://forums.swift.org/u/David_Sweeris)\
**Post date:** [June 19, 2017, 9:43pm UTC](https://forums.swift.org/t/floating-point-numbers-implicit-conversion/6129/17 "2017-06-19T21:43:30Z")

</div>

How expensive is it?

- Dave Sweeris

> **···**
>
> Sent from my iPhone
> 
> > On Jun 19, 2017, at 13:44, John McCall via swift-evolution \<swift-evolution@swift.org\> wrote:
> > 
> > > > On Jun 19, 2017, at 1:58 PM, Stephen Canon via swift-evolution \<swift-evolution@swift.org\> wrote:  
> > > > On Jun 19, 2017, at 11:46 AM, Ted F.A. van Gaalen via swift-evolution \<swift-evolution@swift.org\> wrote:
> > > > 
> > > > var result: Float = 0.0  
> > > > result = float \* integer \* uint8 + double  
> > > > // here, all operands should be implicitly promoted to Double before the complete expression evaluation.
> > > 
> > > You would have this produce different results than:
> > > 
> > > &nbsp;&nbsp;let temp = float \* integer \* uint8  
> > > &nbsp;&nbsp;result = temp + double
> > > 
> > > That would be extremely surprising to many unsuspecting users.
> > > 
> > > Don’t get me wrong; I \*really want\* implicit promotions (I proposed one scheme for them way back when Swift was first unveiled publicly).
> > 
> > I don't! At least not for floating point. It is important for both reliable behavior and performance that programmers understand and minimize the conversions they do between different floating-point types.

---

<div class="post-metadata">

**Author:** ![John\_McCall](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/john_mccall/32/1351_2.png) [@John\_McCall](https://forums.swift.org/u/John_McCall)\
**Post date:** [June 19, 2017, 8:44pm UTC](https://forums.swift.org/t/floating-point-numbers-implicit-conversion/6129/18 "2017-06-19T20:44:22Z")

</div>

I don't! At least not for floating point. It is important for both reliable behavior and performance that programmers understand and minimize the conversions they do between different floating-point types.

John.

> **···**
>
> > On Jun 19, 2017, at 1:58 PM, Stephen Canon via swift-evolution \<swift-evolution@swift.org\> wrote:
> > 
> > > On Jun 19, 2017, at 11:46 AM, Ted F.A. van Gaalen via swift-evolution \<swift-evolution@swift.org \<mailto:swift-evolution@swift.org\>\> wrote:
> > > 
> > > var result: Float = 0.0  
> > > result = float \* integer \* uint8 + double  
> > > // here, all operands should be implicitly promoted to Double before the complete expression evaluation.
> > 
> > You would have this produce different results than:
> > 
> > &nbsp;&nbsp;let temp = float \* integer \* uint8  
> > &nbsp;&nbsp;result = temp + double
> > 
> > That would be extremely surprising to many unsuspecting users.
> > 
> > Don’t get me wrong; I \*really want\* implicit promotions (I proposed one scheme for them way back when Swift was first unveiled publicly).

---

<div class="post-metadata">

**Author:** ![John\_McCall](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/john_mccall/32/1351_2.png) [@John\_McCall](https://forums.swift.org/u/John_McCall)\
**Post date:** [June 19, 2017, 10:08pm UTC](https://forums.swift.org/t/floating-point-numbers-implicit-conversion/6129/19 "2017-06-19T22:08:24Z")

</div>

If memory serves, it's not usually ruinously expensive on its own, but there tend to not be very many functional units for it, and it doesn't get pipelined very well. Essentially, micro-architects often assume that well-written FP code is not doing a significant number of FP conversions. Even if it were very cheap, it would still be an unnecessary operation in the pipeline.

It's a well-known source of performance bugs in C to accidentally use 1.0 instead of 1.0f in the middle of some complex expression that's heavily working with floats. A bunch of intermediate computations ends up getting done in double, and unlike the analogous situation with integers, it's not really possible for the compiler to automatically figure out that it can do them in float instead.

John.

> **···**
>
> > On Jun 19, 2017, at 5:43 PM, David Sweeris \<davesweeris@mac.com\> wrote:  
> > Sent from my iPhone  
> > On Jun 19, 2017, at 13:44, John McCall via swift-evolution \<swift-evolution@swift.org \<mailto:swift-evolution@swift.org\>\> wrote:
> > 
> > > > On Jun 19, 2017, at 1:58 PM, Stephen Canon via swift-evolution \<swift-evolution@swift.org \<mailto:swift-evolution@swift.org\>\> wrote:
> > > > 
> > > > > On Jun 19, 2017, at 11:46 AM, Ted F.A. van Gaalen via swift-evolution \<swift-evolution@swift.org \<mailto:swift-evolution@swift.org\>\> wrote:
> > > > > 
> > > > > var result: Float = 0.0  
> > > > > result = float \* integer \* uint8 + double  
> > > > > // here, all operands should be implicitly promoted to Double before the complete expression evaluation.
> > > > 
> > > > You would have this produce different results than:
> > > > 
> > > > &nbsp;&nbsp;let temp = float \* integer \* uint8  
> > > > &nbsp;&nbsp;result = temp + double
> > > > 
> > > > That would be extremely surprising to many unsuspecting users.
> > > > 
> > > > Don’t get me wrong; I \*really want\* implicit promotions (I proposed one scheme for them way back when Swift was first unveiled publicly).
> > > 
> > > I don't! At least not for floating point. It is important for both reliable behavior and performance that programmers understand and minimize the conversions they do between different floating-point types.
> > 
> > How expensive is it?

---

<div class="post-metadata">

**Author:** ![Stephen\_Canon](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/stephen_canon/32/7220_2.png) [@Stephen\_Canon](https://forums.swift.org/u/Stephen_Canon)\
**Post date:** [June 19, 2017, 10:08pm UTC](https://forums.swift.org/t/floating-point-numbers-implicit-conversion/6129/20 "2017-06-19T22:08:44Z")

</div>

On most contemporary hardware, it’s comparable to a floating-point add or multiply. On current generation Intel, it’s actually a little bit more expensive than that. Not catastrophic, but expensive enough that you are throwing away half or more of your performance if you incur spurious conversions on every operation.

This is really common in C and C++ where a naked floating-point literal like 1.2 is double:

&nbsp;&nbsp;float x;  
&nbsp;&nbsp;x \*= 1.2;

Instead of a bare multiplication (current generation x86 hardware: 1 µop and 4 cycles latency) this produces a convert-to-double, multiplication, and convert-to-float (5 µops and 14 cycles latency per Agner Fog).

–Steve

> **···**
>
> > On Jun 19, 2017, at 5:43 PM, David Sweeris \<davesweeris@mac.com\> wrote:
> > 
> > Sent from my iPhone  
> > On Jun 19, 2017, at 13:44, John McCall via swift-evolution \<swift-evolution@swift.org \<mailto:swift-evolution@swift.org\>\> wrote:
> > 
> > > > On Jun 19, 2017, at 1:58 PM, Stephen Canon via swift-evolution \<swift-evolution@swift.org \<mailto:swift-evolution@swift.org\>\> wrote:
> > > > 
> > > > > On Jun 19, 2017, at 11:46 AM, Ted F.A. van Gaalen via swift-evolution \<swift-evolution@swift.org \<mailto:swift-evolution@swift.org\>\> wrote:
> > > > > 
> > > > > var result: Float = 0.0  
> > > > > result = float \* integer \* uint8 + double  
> > > > > // here, all operands should be implicitly promoted to Double before the complete expression evaluation.
> > > > 
> > > > You would have this produce different results than:
> > > > 
> > > > &nbsp;&nbsp;let temp = float \* integer \* uint8  
> > > > &nbsp;&nbsp;result = temp + double
> > > > 
> > > > That would be extremely surprising to many unsuspecting users.
> > > > 
> > > > Don’t get me wrong; I \*really want\* implicit promotions (I proposed one scheme for them way back when Swift was first unveiled publicly).
> > > 
> > > I don't! At least not for floating point. It is important for both reliable behavior and performance that programmers understand and minimize the conversions they do between different floating-point types.
> > 
> > How expensive is it?

[Next page](https://forums.swift.org/t/floating-point-numbers-implicit-conversion/6129.md?page=2)