std.experimental.checkedint is ready for comments!

[tsbockman via Digitalmars-d]

On Wednesday, 15 June 2016 at 18:34:15 UTC, tsbockman wrote:
> On Wednesday, 15 June 2016 at 16:40:19 UTC, Andrei Alexandrescu 
> wrote:
>> Getting to the design: the root of the problem is a byzantine 
>> design that is closed to extension.
>
> The design was closed deliberately because of (8). Template 
> bloat is a major concern, even with the current finite design.
>
> I want `checkedint` to be usable in public APIs, and that 
> requires some standardization of error handling and base types 
> to be enforced upon the users. Otherwise, everyone will choose 
> something different and all template instantiations involving 
> integer types will become practically single-use.
>
>> Looking at the IntFlagPolicy, it offers three canned behavior: 
>> throws, asserts, and noex.
>
> The choice of policies is motivated by the natural 
> incompatibility of (2), (4), (6), and (7). I built in enough 
> variety to allow people to choose their own priorities among 
> those goals, and no more because of (8).

Re-reading what I wrote there, I makes it sound like the closed 
design was motivated solely by template bloat concerns. But, 
that's not true either.

Standardizing the error handling methods is also important for 
other interoperability-related reasons:

     * If every third-party library designs a different error 
handling method,
       people writing applications that depend on many libraries 
will have to
       study the `checkedint` error signaling of each one, and 
make sure that
       their code which interacts with each library knows how to 
detect and
       respond to its particular signaling mechanism.

       My design for `checkedint` reduces the number of 
`checkedint`-specific
       signaling methods that need to be studied down to one (the 
sticky flags
       policy). The other two policies are just using D's standard 
error-
       handling facilities, and don't require any user 
intervention anyway,
       unless you want to catch the exception for some reason.

       Even the sticky flags policy is only of concern for 
`nothrow @nogc` APIs,
       which I suspect in practice will mostly mean game libraries.

     * The relative simplicity of my policy set has allowed me to 
arrange them
       into a strict linear hierarchy, so that the results of 
mixing policies
       is predictable and safe.