[swift-evolution] Implicit Type Conversion For Numerics Where Possible.
Ted F.A. van Gaalen
tedvgiosdev at gmail.com
Wed Mar 30 12:57:45 CDT 2016
Thank you, Robert & Haravikk
Please allow me to respond in-line hereunder, thanks.
Ted.
> On 30.03.2016, at 16:15, Haravikk <swift-evolution at haravikk.me> wrote:
>
> 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
Why? and What cannot 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,
awful, didn’t know that
> 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.
It simply would cause a float with less precision as an integer like
10000 -becomes e.g - 9999.999999, (depending on magnitude, of course)
but that is normal in a floating point domain; E.g. also with:
var v:Double = 10000.0 // Double to Double
v would have the same imprecision… and could be anywhere between 9999.9998…10000.00001
(rough estimation, depending on magnitude and the floating point type used)
>
>> On 30 Mar 2016, at 14:57, Developer via swift-evolution <swift-evolution at swift.org <mailto: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.
E.g. if I assign an Int to a Double, then I know very well what I am doing.
often occurring simple example here:
for i in 0..<10
{
dTemperature = dInterval * i / / Double = Double * Int (not possible yet in Swift)
foo(dTemperature)
}
Here I still have to write:
dTemperature = dInterval * Double(i)
However, Swift will accept:
dTemperature = dInterval * 3 // 3 inferred to Double. could be regarded as an implicit conversion?
>> Once you add implicit type coercions, even just between integer or floating point types, your language gains a hundred unspoken rules
Could you please explain these “unspoken rules” you mention more in detail?
>> and little guard rails you have to cling to lest you slip and hit the next pitfall.
I am counting on the average intelligence of programmers.
>> 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
In practice, the implications/effects/behavior of a programming language
cannot be fully predicted and understood, there are simply too many possibilities,
Functional Programming attempts to solve this, trying to make/do everything mathematically
correct but fails for the aforementioned reason.
>> and serve as yet another hindrance to novices trying to adopt the language.
I don’t agree here. Even novices should have a good understanding
of the basic data types of a programming language,
Also note that concepts of integer, natural, rational, irrational numbers etc.
is very basic mathematics as learned in high school.
or your country’s equivalent education.
So aDouble = anInt should -in the programmer’s mind-
appear as an explicit conversion, that is, he/she should realize the consequences.
The same applies also doing it explicitly like so:
aDouble = Double(anInt)
Same effect: even a fool can use this as well and not knowing the implications.
>>
>> 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,
I wrote that I don’t want implicit conversion for Float -> Int.
>> and Double -> Float, etc. coercions as mere trifles is an attitude I don't want enshrined in the language's type system.
>>
Could you give me an example where Double -> Float is problematic (apart from loosing precision) ?
>> 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).
Please spare me from this kind of contraptions.
-=side note: =-
Thanks for bringing Idris to my attention. Investigating...
Idris is a FP language. I am not against it, but to me, FP is almost unreadable.
I doubt if I will ever use it.
I use strictly OOD/OOP. It’s natural. Like in Smalltalk. Proven. Solid.
For now, the only reason I use protocols in Swift are to accommodate delegating/callbacks.
-= end side note =-
>> 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.
To me, there is no unintended information loss, because I know what I am doing regarding implicit conversion.
Then again, in all the cases for which I suggested implicit data type conversion, there is no data loss (apart from precision)
TedvG
>>
>> ~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 <mailto: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/dee4fd92/attachment.html>
More information about the swift-evolution
mailing list