[swift-evolution] Implicit Type Conversion For Numerics Where Possible.

[Stephen Canon]

On Mar 30, 2016, at 1:35 PM, Ted F.A. van Gaalen via swift-evolution <swift-evolution at swift.org> wrote:

>> 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) 

Rounding in a conversion is data loss, full stop.  It will be extremely difficult (impossible, really) to convince folks that explicit conversion should not be required when the value might be changed.

If you restrict to cases where it is exact, implicit conversion is much more palatable, but you’re then left with a system in which Int32 can implicitly convert to Double, but not to Float.  The added confusion of such a system is significant, but I can at least imagine that one could make a case for it.

What you’re much more likely to get traction with is reducing the need for conversions at all, implicit or explicit.  The Integers prototype that Dave and Max have been working on (test/Prototypes/Integers.swift.gyb) starts to move in this direction by allowing heterogeneous integer types in shifts and comparisons.  This is a great approach because it eliminates the need for conversion entirely, rather than making them implicit.  Shifts and comparisons cover a large portion of the cases where the need for conversions is most painful, and this doesn’t introduce risk because the result type and value are clearly and unambiguously defined by the values involved (and the lhs type for shifts).

– Steve

PS: personally as someone who has a firm grasp of low-level numerics, I find the need for explicit conversions annoying, but it’s only a very minor annoyance, and I appreciate the safety that it provides for users who wisely don’t want to waste mental capacity on the precise details of numeric ranges and conversions.  On balance I think requiring them to be explicit is a significant win.

I would also be remiss if I didn’t observe that excessive conversions, implicit or explicit, are a significant performance hazard.  Even in the best-case scenario, they often require a sign- or zero-extension instruction.  They may also involve testing for out-of-range values and trapping, or (as with unsigned integer to floating-point on x86) a sequence of several instructions.  To some extent, this is a case of “if it hurts, don’t do it”.