On 1/24/14 6:08 AM, Dominikus Dittes Scherkl wrote:
On Friday, 24 January 2014 at 13:30:06 UTC, Meta wrote:
On the Rust mailing list, there's recently been discussion about auto-promotion
to BigInt in case
of overflow. Maybe that's a discussion we should be having as well?
Nice idea. But is any overflow known at compile-time?
Also really unexpected auto-type...
I had something very simple in mind:
1) get rid of the asymmetric T.min value
that always causes problems with abs()
2) instead use this special value as NaN
3) let NaN be the init-value of the signed types
4) let every over-/underflow result in NaN
5) let every operation involving NaN result in NaN
5) let any cast from other types to the save
signed types check range and set NaN if the
value doesn't fit
None of that should be too expensive, but with such a type you can simply
execute the program and if
it result in NaN you know there had been some overflow (or uninitialized
variable). That makes
analyzing easy, it allows for simple contracts, is easy to catch and allows
easy to decide what
solution would be the best (e.g. using next bigger type or limit the values).
And if performance is critical (which should be true only in some inner loop
where one can be sure
that no overflow is possible) as next step the now fool-prove program can be
changed to use unsave
types (because they use the same range + one extra value that hopefully never
occures anyway).
The only reason that NaN works in the FP world is that it's done in hardware as part of existing
operations. For it to work in the integer world it'd require adding operations to do the extra
checking and handling with the resulting performance costs of doing so. It's, pretty much by
definition, too expensive for a set of people and the apps they care about. The only practical way
is to introduce a new type that behaves like this and use that instead. If, over the course of
years, becomes popular enough, it's not impossible that some cpu makers could decide to enshrine it
in new instructions. But I wouldn't hold your breath. :)
None of this is new. It comes up periodically and ends up in the typical place of many feature
requests, unimplemented. Create the type, share it, see who uses it and how much they gain from the
benefits and if they're worth the costs. Conjecture will only get you so far.
My 2 cents,
Brad
