Re: [swift-evolution] In-line scope designators

[Rien via swift-evolution]

I don’t like this, it violates the locality principle. I.e. that all 
information that is needed to understand something is close by.

But since it is not something that everybody has to use… I don’t object to it 
either.

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl - An HTTP(S) web server framework in Swift







> On 17 Jun 2017, at 23:48, Ted F.A. van Gaalen via swift-evolution 
>  wrote:
> 
> (I am not sure if I should tag this subject with [pitch]? ) 
> 
> Please don’t worry , I am not attempting to start a new
> and infinite thread about whether or not the way scope
> is handled in Swift is imho correct or not.
> Errhm well, apart from that “protected” is missing,
> but please let us not start again.. :o) 
> 
> No, it is more or less a convenience solution to
> prevent unnecessary wear and tear to the following keys
> on my keyboard: [ A,E, I, P,  R, T, V]
> 
> I prefer it, not to expose those class or struct members
> which should not be accessible outside the class or struct
> 
> Currently, to prevent access to private Items,
> I have to type the word “private” too many times:
> 
> class  House
> {
> private var rooms = 5
>   private var roofTiles = 11201
>   private let paint =   UIColor.Blue;
> private var yearTax: Money = “323,56"
> private let garageVolume = 60.0
> 
> init(..) {.. }
> 
>  private func calculateTax() {...}
> 
>  public func roomsUnoccupied() -> Int {…}
> 
> func roofData(……) {…}
> 
>  private func  a{…} 
> }
> 
> To set the scope of a list of members I suggest the
> “in-line scope modifiers”  (anyone with a better name for it?) 
> 
> For example if one has a source line containing the word
> “private:” then all the following member declarations will
> be “private” until another inline scope modifier is encountered
> with one “default scope” to escape from it. like in the following example”
> 
> The compiler can detect that it is an inline scope modifier, because it ends 
> with a colon
> 
> “Normal” scope modifiers, that is the ones which precede the member’s name 
> directly should imho not be allowed within such a scope block.
> unless they would override for that specific item, but that looks ugly. 
> 
> getter & setters and init should appear in default scope
> (or with no in-line scope modifiers)
> 
> Inline scope modifiers can be specified as often as
> desired and in arbitrary sequence. 
> 
> 
> class  House
> {
>  init(..) {.. }
> private:// <——  In-line scope 
> modifier all following declarations are private here.
> var rooms = 5
>   var roofTiles = 11201
>   let paint =   UIColor.Blue;
> var yearTax: Money = “323,56"
> func calculateTax() {…}
> func  a{…} 
> 
>   public: // <——  In-line 
> scope modifier
>  var garageVolume = 60.0  
>  func roomsUnoccupied() -> Int {…}
>  func roofData(……) {…}
> 
>   defaultscope: // <—— Return to default 
> scope (only needed when preceding inline scope modifiers are present. )
>  
>   func sellHouse(buyer: CustomerID)   
> }
> 
> See? looks a lot better, don’t you think so?  
> it also makes sources more readable because one can 
> now conveniently group items.
> 
> 100% source compatible with whatever scope 
> mechanism now or in the future is or will be deployed.
> 
> 
> (The idea is not exactly new, a similar construct is available in Object 
> Pascal.)  
> 
> ?
> 
> Kind Regards
> TedvG
> 
> 
> 
> 
> 
> 
>  
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] floating point numbers implicit conversion

[John McCall via swift-evolution]

> On Jun 19, 2017, at 5:43 PM, David Sweeris  wrote:
> Sent from my iPhone
> On Jun 19, 2017, at 13:44, John McCall via swift-evolution 
> > wrote:
> 
>>> On Jun 19, 2017, at 1:58 PM, Stephen Canon via swift-evolution 
>>> > wrote:
 On Jun 19, 2017, at 11:46 AM, Ted F.A. van Gaalen via swift-evolution 
 > 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:
>>> 
>>> let temp = float * integer * uint8
>>> 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?

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.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Core team] Addressing the SE-0110 usability regression in Swift 4

[Nevin Brackett-Rozinsky via swift-evolution]

Yay!
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Core team] Addressing the SE-0110 usability regression in Swift 4

[Douglas Gregor via swift-evolution]

Hello Swift community,

Swift 3’s SE-0110 

 eliminated the equivalence between function types that accept a single type 
and function types that take multiple arguments. However, for various 
implementation reasons 
,
 the implementation of SE-0110 (as well as the elimination of tuple “splat” 
behavior in SE-0029 
)
 was not fully completed.

Swift 4 implemented more of SE-0110, which caused a fairly serious usability 
regression, particularly with closures. Here are a few simple examples 
involving closures that worked in Swift 3 but do not work in Swift 4:

// #1: Works in Swift 3, error in Swift 4
myDictionary.forEach {
  print("\($0) -> \($1)")
}

// #2: Works in Swift 3, error in Swift 4
myDictionary.forEach { key, value in
  print("\(key) -> \(value)")
}

// #3: Works in Swift 3, error in Swift 4
myDictionary.forEach { (key, value) in
  print("\(key) -> \(value)")
}

Similar issues occur with passing multi-argument functions where a tuple 
argument is expected:

// #4: Works in Swift 3, error in Swift 4
_ = zip(array1, array2).map(+)

In all of these cases, it is possible to write a closure that achieves the 
desired effect, but the result is more verbose and less intuitive:

// Works in both Swift 3 and Swift 4
myDictionary.forEach { element in
  let (key, value) = element
  print("\(key) -> \(value)")
}

The Swift core team feels that these usability regressions are unacceptable for 
Swift 4. There are a number of promising solutions that would provide a better 
model for closures and address the usability regression, but fully designing 
and implementing those are out of scope for Swift 4.  Therefore, we will “back 
out” the SE-0110 change regarding function arguments from Swift 4.

Specifically, when passing an argument value of function type (including 
closures) to a parameter of function type, a multi-parameter argument function 
can be passed to a parameter whose function type accepts a single tuple (whose 
tuple elements match the parameter types of the argument function). Practically 
speaking, all of the examples #1-#4 will be accepted in both Swift 3 and Swift 
4.

We will revisit the design in this area post-Swift 4.

- Doug

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] In-line scope designators

[Haravikk via swift-evolution]

> On 19 Jun 2017, at 21:40, David Sweeris via swift-evolution 
>  wrote:
> 
> 
>> On Jun 19, 2017, at 11:45, Robert Bennett via swift-evolution 
>>  wrote:
>> 
>> +1 for member variables, -1 for member functions. Functions take up too much 
>> vertical space to make this convenient; 
> 
> Yeah, I think that really only made sense in the world of header files, where 
> function declarations were only one line each.
> 
> Off the top of my head, I wouldn't oppose it for non-computed properties, 
> though.

Wouldn't a load of restrictions make it more complex to implement? I would say 
that if the feature was to be implemented it should just work for everything; 
this makes it a lot simpler to implement and just leaves it up to developers to 
decide where it is most appropriate to use it.

After all, very simple computed properties, lazy values and other functions can 
be written on a single line if you really want to do it, so it seems like this 
feature would be just as useful for those as well.

I'd probably keep them limited to type declarations though; i.e- not in 
extensions, since they can already declare visibility (except extensions for 
conformance, which imply a visibility).
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] floating point numbers implicit conversion

[Stephen Canon via swift-evolution]

> On Jun 19, 2017, at 5:43 PM, David Sweeris  wrote:
> 
> Sent from my iPhone
> On Jun 19, 2017, at 13:44, John McCall via swift-evolution 
> > wrote:
> 
>>> On Jun 19, 2017, at 1:58 PM, Stephen Canon via swift-evolution 
>>> > wrote:
 On Jun 19, 2017, at 11:46 AM, Ted F.A. van Gaalen via swift-evolution 
 > 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:
>>> 
>>> let temp = float * integer * uint8
>>> 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?

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:

float x;
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___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] floating point numbers implicit conversion

[David Sweeris via swift-evolution]

Sent from my iPhone
> On Jun 19, 2017, at 13:44, John McCall via swift-evolution 
>  wrote:
> 
>>> On Jun 19, 2017, at 1:58 PM, Stephen Canon via swift-evolution 
>>>  wrote:
>>> On Jun 19, 2017, at 11:46 AM, Ted F.A. van Gaalen via swift-evolution 
>>>  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:
>> 
>>  let temp = float * integer * uint8
>>  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?

- Dave Sweeris ___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] floating point numbers implicit conversion

[John McCall via swift-evolution]

> On Jun 19, 2017, at 1:58 PM, Stephen Canon via swift-evolution 
>  wrote:
>> On Jun 19, 2017, at 11:46 AM, Ted F.A. van Gaalen via swift-evolution 
>> > 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:
> 
>   let temp = float * integer * uint8
>   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.

John.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] In-line scope designators

[David Sweeris via swift-evolution]

> On Jun 19, 2017, at 11:45, Robert Bennett via swift-evolution 
>  wrote:
> 
> +1 for member variables, -1 for member functions. Functions take up too much 
> vertical space to make this convenient; 

Yeah, I think that really only made sense in the world of header files, where 
function declarations were only one line each.

Off the top of my head, I wouldn't oppose it for non-computed properties, 
though.

- Dave Sweeris
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] In-line scope designators

[Robert Bennett via swift-evolution]

+1 for member variables, -1 for member functions. Functions take up too much 
vertical space to make this convenient; you’d constantly be scrolling around to 
view or modify the access level of a function. Plus I tend to group functions 
by use — private functions go directly above the public function that calls 
them. But member declarations are often one or just a few lines, and 
additionally are often grouped by access level anyway (at least that’s how I do 
it) so this provides a compact way to group them.


> On Jun 17, 2017, at 5:48 PM, Ted F.A. van Gaalen via swift-evolution 
>  wrote:
> 
> (I am not sure if I should tag this subject with [pitch]? ) 
> 
> Please don’t worry , I am not attempting to start a new
> and infinite thread about whether or not the way scope
> is handled in Swift is imho correct or not.
> Errhm well, apart from that “protected” is missing,
> but please let us not start again.. :o) 
> 
> No, it is more or less a convenience solution to
> prevent unnecessary wear and tear to the following keys
> on my keyboard: [ A,E, I, P,  R, T, V]
> 
> I prefer it, not to expose those class or struct members
> which should not be accessible outside the class or struct
> 
> Currently, to prevent access to private Items,
> I have to type the word “private” too many times:
> 
> class  House
> {
> private var rooms = 5
>   private var roofTiles = 11201
>   private let paint =   UIColor.Blue;
> private var yearTax: Money = “323,56"
> private let garageVolume = 60.0
> 
> init(..) {.. }
> 
>  private func calculateTax() {...}
> 
>  public func roomsUnoccupied() -> Int {…}
> 
> func roofData(……) {…}
> 
>  private func  a{…} 
> }
> 
> To set the scope of a list of members I suggest the
> “in-line scope modifiers”  (anyone with a better name for it?) 
> 
> For example if one has a source line containing the word
> “private:” then all the following member declarations will
> be “private” until another inline scope modifier is encountered
> with one “default scope” to escape from it. like in the following example”
> 
> The compiler can detect that it is an inline scope modifier, because it ends 
> with a colon
> 
> “Normal” scope modifiers, that is the ones which precede the member’s name 
> directly should imho not be allowed within such a scope block.
> unless they would override for that specific item, but that looks ugly. 
> 
> getter & setters and init should appear in default scope
> (or with no in-line scope modifiers)
> 
> Inline scope modifiers can be specified as often as
> desired and in arbitrary sequence. 
> 
> 
> class  House
> {
>  init(..) {.. }
> private:// <——  In-line scope 
> modifier all following declarations are private here.
> var rooms = 5
>   var roofTiles = 11201
>   let paint =   UIColor.Blue;
> var yearTax: Money = “323,56"
> func calculateTax() {…}
> func  a{…} 
> 
>   public: // <——  In-line 
> scope modifier
>  var garageVolume = 60.0  
>  func roomsUnoccupied() -> Int {…}
>  func roofData(……) {…}
> 
>   defaultscope: // <—— Return to default 
> scope (only needed when preceding inline scope modifiers are present. )
>  
>   func sellHouse(buyer: CustomerID)   
> }
> 
> See? looks a lot better, don’t you think so?  
> it also makes sources more readable because one can 
> now conveniently group items.
> 
> 100% source compatible with whatever scope 
> mechanism now or in the future is or will be deployed.
> 
> 
> (The idea is not exactly new, a similar construct is available in Object 
> Pascal.)  
> 
> ?
> 
> Kind Regards
> TedvG
> 
> 
> 
> 
> 
> 
>  
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] floating point numbers implicit conversion

[Stephen Canon via swift-evolution]

> On Jun 19, 2017, at 11:46 AM, Ted F.A. van Gaalen via swift-evolution 
>  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:

let temp = float * integer * uint8
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___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] In-line scope designators

[Ted F.A. van Gaalen via swift-evolution]

(I am not sure if I should tag this subject with [pitch]? ) 

Please don’t worry , I am not attempting to start a new
and infinite thread about whether or not the way scope
is handled in Swift is imho correct or not.
Errhm well, apart from that “protected” is missing,
but please let us not start again.. :o) 

No, it is more or less a convenience solution to
prevent unnecessary wear and tear to the following keys
on my keyboard: [ A,E, I, P,  R, T, V]

I prefer it, not to expose those class or struct members
which should not be accessible outside the class or struct

Currently, to prevent access to private Items,
I have to type the word “private” too many times:

class  House
{
private var rooms = 5
private var roofTiles = 11201
private let paint =   UIColor.Blue;
private var yearTax: Money = “323,56"
private let garageVolume = 60.0

init(..) {.. }

 private func calculateTax() {...}

 public func roomsUnoccupied() -> Int {…}

func roofData(……) {…}

 private func  a{…} 
}

To set the scope of a list of members I suggest the
“in-line scope modifiers”  (anyone with a better name for it?) 

For example if one has a source line containing the word
“private:” then all the following member declarations will
be “private” until another inline scope modifier is encountered
with one “default scope” to escape from it. like in the following example”

The compiler can detect that it is an inline scope modifier, because it ends 
with a colon

“Normal” scope modifiers, that is the ones which precede the member’s name 
directly should imho not be allowed within such a scope block.
unless they would override for that specific item, but that looks ugly. 

getter & setters and init should appear in default scope
(or with no in-line scope modifiers)

Inline scope modifiers can be specified as often as
desired and in arbitrary sequence. 


class  House
{
   init(..) {.. }
private:// <——  In-line scope 
modifier all following declarations are private here.
var rooms = 5
var roofTiles = 11201
let paint =   UIColor.Blue;
var yearTax: Money = “323,56"
func calculateTax() {…}
func  a{…} 

  public: // <——  In-line scope 
modifier
 var garageVolume = 60.0  
 func roomsUnoccupied() -> Int {…}
 func roofData(……) {…}

  defaultscope: // <—— Return to default 
scope (only needed when preceding inline scope modifiers are present. )
 
  func sellHouse(buyer: CustomerID)   
}

See? looks a lot better, don’t you think so?  
it also makes sources more readable because one can 
now conveniently group items.

100% source compatible with whatever scope 
mechanism now or in the future is or will be deployed.


(The idea is not exactly new, a similar construct is available in Object 
Pascal.)  

?

Kind Regards
TedvG






 ___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] floating point numbers implicit conversion

[Ted F.A. van Gaalen via swift-evolution]

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

> On 16. Jun 2017, at 18:19, Xiaodi Wu  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.
> 
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





> On Fri, Jun 16, 2017 at 11:08 Ted F.A. van Gaalen via swift-evolution 
> > 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: 

Re: [swift-evolution] floating point numbers implicit conversion

[Ted F.A. van Gaalen via swift-evolution]

> On 18. Jun 2017, at 08:04, Xiaodi Wu  wrote:
> 
> On Sun, Jun 18, 2017 at 00:02 Brent Royal-Gordon  > wrote:
>> On Jun 17, 2017, at 8:43 PM, Xiaodi Wu via swift-evolution 
>> > 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.
> 
> 
> 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) 
  should all implicitly be promoted to lowest possible precision
 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
  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. 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.