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 <mailto: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 <mailto: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 >>> >>> <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 <mailto:swift-evolution@swift.org> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto: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