On 6/25/16 10:38 AM, Robert burner Schadek wrote:
On Friday, 24 June 2016 at 21:31:14 UTC, Andrei Alexandrescu wrote:
By default, if Hook has no state and implements none of these methods,
e.g. is void, then Checked!(int, void) is a user-defined type that
mimics the behavior of int to the maximum extent possible.
I think there is a major problem with the proposed design.
when Checked!(int, void) is to behave as an int, why do we need it in
the first place. I mean we have int as a basic type. Can't we do:
alias Int = int;
alias Int = Checked!(int, SomeUsefulHook);
On second thought, the only feature of Checked!(int, void) is to be a
slower int ;-)
Thanks for the feedback. There is at least one place in which built-in
integrals are not entirely replaceable - literals. Consider:
byte a = 0;
short b = -1;
ushort c = 1;
All of the literals involved have type int, so in theory neither line
should work. However, the compiler special-cases literals because it
"knows" they are within bounds. This special casing is inaccessible to
user-defined types.
So it stands to reason that if you want to design a checked integral
types offering a variety of checking policies, one point in the design
space that needs to be attainable is "no checks at all". Then the
syntactic shell works the same as with any policy, and ideally there's
no overhead at all.
IMO the default CheckedInt!(int, void) needs a NaN like init/failure
state. After any operation that overflows the value should be NaN.
One good design principle is pushing policy up and implementation down.
A NaN is a very specific policy, which is appropriate for a Hook
definition but would look out of place in the Checked shell.
Andrei
