[swift-evolution] Implicit Type Conversion For Numerics Where Possible.

[Haravikk]

I’m in favour of implicit conversion for integers where no data can be lost (UInt32 to Int64, Int32 to Int64 etc.), in fact I posted a similar thread a little while ago but can’t find it; there’s something being done with numbers so this may be partly in the works.

I definitely think that implicit conversion for floating point should be avoided, as it can’t be guaranteed except in certain edge cases; for example, Javascript actually technically uses a double for all of its numeric types, effectively giving it a 52-bit (iirc) integer type, so in theory conversion of Int32 to Double is fine, and Int16 to Float might be as well, but I’m not certain if it’s a good idea or not, as it’s not quite the same as just extending the value.

> On 30 Mar 2016, at 14:57, Developer via swift-evolution <swift-evolution at swift.org> wrote:
> 
> What you describe, all those cases where one fixes losing precision by simply "ignoring it", that's part of why I'm hesitant about simply throwing in C-like promotion rules into any language.  Once you add implicit type coercions, even just between integer or floating point types, your language gains a hundred unspoken rules and little guard rails you have to cling to lest you slip and hit the next pitfall.  Though you may be dismissive of information loss, it is a serious issue in coercions, and one with implications that are never completely grokked by experts and serve as yet another hindrance to novices trying to adopt the language. 
> 
> So, I don't think coercion under this scheme is the complete end-all-be-all solution to this problem, [though it may certainly feel right].  Sure, it is always defined behavior to "downcast" a value of a lower bitwidth to one of a higher bitwidth, but to dismiss Int -> Float, Float -> Int, and Double -> Float, etc. coercions as mere trifles is an attitude I don't want enshrined in the language's type system.
> 
> Perhaps there is a middle ground.  Say, one could declare conformance to a special kind of protocol declaring safe implicit convertibility (see: Idris' solution of having an `implicit` conversion mechanism). Or perhaps a good first step may be to not deal with information loss at all, and only keep the parts of this proposal that are always defined behavior.
> 
> ~Robert Widmann
> 
> 2016/03/30 8:01、Ted F.A. van Gaalen via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> のメッセージ:
> 
>> Currently, one has to deal with explicit conversion between numerical types,
>> which in many cases is unnecessary and costing time to code 
>> for things that are quite obvious,
>> and cluttering the source, making it less readable.
>> 
>> Especially dealing all the time with often unavoidable intermixing 
>> of floating point types CGFloat, Float, and Double 
>> is really very annoying. 
>> 
>> Conversion beween floating point types is always harmless as 
>> floating point types are essentially the same. 
>> They differ only in precision.
>> 
>> Therefore, I would recommend allowing the following implicit type conversions:
>> 
>> -between all floating point types e.g. Double, Float, CGFloat  
>> 
>> -from any integer type to floating point types
>> 
>> -Also, personally, I wouldn’t mind assigning from a float to a (signed) integer
>> because I know what I am doing: that the fraction is lost 
>> and that assigning a too large float to an Integer would then cause 
>> a run time error, which I can try/catch, of course. 
>> 
>> -from unsigned integer to signed integer   
>> (nothing is lost here, but overflow should cause a run time error) 
>> 
>> but no implicit conversion for:
>> - from integer to unsigned integer   (loosing sign here)
>> - from a larger integer type to a smaller one e.g.   Int32 <- Int64   (truncation)  
>> 
>> Note however, that the compiler should issue warnings 
>> when you do implicit conversions, but these warnings 
>> are for most programmers of the “Yeah I know, don’t bug me.”
>> type, so one should be able to switch off these type of warnings.
>> 
>> Even a programmer with little experience simply knows 
>> that bringing integers into the floating point domain 
>> causes precision loss. 
>> He/she also knows that assigning a Double to a smaller floating
>> point type also cause precision loss.  
>> the reverse is not true.
>> 
>> 
>> Very much interested in your opinion!
>> 
>> ----
>> N.B. the above does not yet include 
>> the fixed decimal numerical type as this type is not yet
>> available in Swift.  However, it should be  implemented 
>> *as soon as possible*  because the fixed decimal type 
>> is really needed for applications working with financial data!
>> E.g. 
>> var depositPromille: Decimal(10,3)
>> typealias  Money = Decimal(20,2) 
>>   
>> For more info on how this could be implemented
>> in Swift. please read a PL/1 manual, ( i grew up in this world)
>> like this one: 
>> 
>> http://www.ibm.com/support/knowledgecenter/#!/SSY2V3_4.3.0/com.ibm.entpli.doc_4.3/lr/preface_plugin.htm <http://www.ibm.com/support/knowledgecenter/#!/SSY2V3_4.3.0/com.ibm.entpli.doc_4.3/lr/preface_plugin.htm>
>> 
>> especially under sub-topic “Data elements” 
>> 
>> (however, don’t take everything for granted, PL/1 is still a very young language :o) 
>> Unfortunately OOP never made it into PL/1 because with it, it would be nearly perfect.)
>> 
>> Should I make a new swift-evolution topic for fixed decimal?
>> 
>> Kind Regards
>> TedvG
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160330/4fa0ed35/attachment.html>