You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was kind of thinking that it might. It's sort of a different approach to "down conversion": if you're faced with a conversion to a less capable type that's going to lose significant information, like rounding a non-integral float, throw an exception. The idea would be that convert(Int, x::Float64) throws an error if the float isn't an exact integer-valued float, since this is often used generically under the assumption that the conversion is safe (indexing, field assignment, ccall). If you just want to do rounding conversion, regardless of such subtleties, you do int(x::Float64), which has to be written explicitly, implying that you're fine with whatever losses.
However, this approach would imply that convert(Int8, typemax(Int64)) should throw an error, which tosses a wrench into our whole scheme for just converting down at the end of integer computations. That's not a can of worms I really want to open again :-\
All of this kind of reminds me of the distinction I once wanted to make between convert and coerce: convert is the "gentle" version — if the value doesn't fit, it throws an exception; coerce is the more forceful version. All the conversions we have now are forceful, but it's handy to have gentler versions, which is why we're concerned about things like indexing, field assignment.
As a corollary, we can reinstate automatic conversion of fields to constructors after this.
The text was updated successfully, but these errors were encountered: