On 06/15/2016 02:26 PM, Walter Bright wrote:
On 6/15/2016 9:40 AM, Andrei Alexandrescu wrote:
Looking at the IntFlagPolicy, it offers three canned behavior: throws,
asserts,
and noex. Users cannot customize behavior and there is no information
passed
into the policy (e.g. the operands in case of overflow, or the
numerator in case
of division by zero). Passing the appropriate information would make
it possible
to implement various policies, e.g. the policy cannot say "I'm
actually okay
with this" or "here I'll implement a saturation policy".
Just a note to add to these excellent comments. One style of integer
arithmetic is "saturation" arithmetic, whereby if it overflows, instead
of an error it gets "stuck" at T.max. Same for underflow.
https://en.wikipedia.org/wiki/Saturation_arithmetic
A good test for a policy API design is if saturation behavior could be
done with a user-defined policy, instead of it being a pre-defined one.
Also, the proposed design mentions "hysteresis" and allows Hook to
introduce state. -- Andrei
