+1
I am strictly against implicit conversions where data loss may happen.
I am even against implicit conversions which are just expensive.
With regards to the argument of counting on the developers intelligence I think
that is a task for compilers just like type checking.
-Thorsten
> Am 30.03.2016 um 23:38 schrieb Developer via swift-evolution
> <swift-evolution@swift.org>:
>
>
>
>
>>> On Mar 30, 2016, at 4:35 PM, Ted F.A. van Gaalen <tedvgios...@gmail.com>
>>> wrote:
>>>
>>>
>>> On 30.03.2016, at 20:29, Developer <devteam.cod...@gmail.com> wrote:
>>>
>>> I believe section 6.3 of the ISO/C99 specification describes its integer
>>> promotion rules and Appendix J describes undefined behavior as a
>>> consequence of integer and floating point coercion. I refer to these when
>>> I speak of "rules”.
>> Although ISO compliance makes sense in a lot of cases, for programming
>> languages,
>> these rules are extremely bureaucratic, restricting and always far behind
>> fast developments in
>> IT. Would you like to see Swift to be ISO compliant?
>> Then you could throw away perhaps more than half the language constructs
>> currently present in Swift?
>>
>> @Chris:
>>
>> is there a desire/requirement to make Swift ISO compliant?
>> and thus therewith restricting Swift’s flexibility? If so, to what extent?
>
> This is orthogonal to the discussion at hand.
>
>>>
>>> As long as data loss is an "unintended" effect of a certain class of
>>> coercions, I don't believe it deserves to be implicit. If you "know what
>>> you're doing", the preference so far has been to tell the compiler that and
>>> use the constructors provided in the Swift Standard Library to perform
>>> explicit truncation. Even in C, if you can be more specific with a cast in
>>> cases where you intend data loss, you probably should be.
>> With all due respect, Robert, Imho, I find this all too theoretical and
>> bureaucratic and tons of unnecessary overhead.
>> and I am telling the compiler implicitly:
>> aFloat = anInt // The compiler will use a builtin function to do the
>> conversion. what can be wrong with that?
>> Again, in the cases I mentioned there is no data loss. (precision excluded)
>
> An example of “data loss”, then (adapted from the wonderful example given by
> Felix Cloutier here). Be judicious running this, it will spin for quite a
> while if you don’t kill it first.
>
> import Darwin
>
> for i in Int(INT_MAX).stride(to: 0, by: -1) {
> let value : Float = Float(i)
> let ivalue : Int = Int(value)
> if (i != ivalue) {
> print("Integer \(i) is represented as \(ivalue) in a float\n")
> }
> }
>
>
> You may still argue, however, that loss of precision is not as egregious as
> full-on truncation, but it is still data loss all the same. If it is too
> technical and bureaucratic to insert casts to make your intent clear in
> either language (rather than what I assume is just silencing -Wconversion),
> I’ll take bureaucracy and safety over convenience please.
>
> ~Robert Widmann
>
>>
>>>
>>> ~Robert Widmann
>>>
>>> 2016/03/30 13:57、Ted F.A. van Gaalen <tedvgios...@gmail.com> のメッセージ:
>>>
>>>> Thank you, Robert & Haravikk
>>>> Please allow me to respond in-line hereunder, thanks.
>>>> Ted.
>>>>> On 30.03.2016, at 16:15, Haravikk <swift-evolut...@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@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@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
>>>>>>>
>>>>>>> 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@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
>
> _______________________________________________
> 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
