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 > <[email protected]> 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 > <[email protected] <mailto:[email protected]>> のメッセージ: > >> 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 >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
