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