std.experimental.checkedint is ready for comments!

[tsbockman via Digitalmars-d]

On Thursday, 16 June 2016 at 00:31:38 UTC, Andrei Alexandrescu 
wrote:
> On 06/15/2016 02:50 PM, tsbockman wrote:
>> What you are proposing is *not* "fixing" my design - it is 
>> basically
>> scrapping it and replacing it with a ground-up rewrite, with 
>> perhaps
>> some bits and pieces and general inspiration taken from my 
>> work.
>
> I'd say that's a fair assessment on the face of it. But the 
> pieces are there and the grit and expertise to assemble them 
> are already there. The real question is what's the "right" 
> design. Ideally we should optimize for that.

I set out to solve a specific problem with `checkedint`, and I 
believe my design succeeds in the areas that it is intended to, 
to the extent that is reasonably possible with D today.

In order to convince me to rewrite this, you would need to 
convince me that *my* goals can be met significantly better by a 
different library design. So far, I see no evidence of this.

You are of course free to set different goals than I have, but 
from my perspective this is *major* scope creep, and not what I 
volunteered for.

>> I'm OK with the community rejecting my design if that's what 
>> people
>> really want to do, but I will not be implementing your 
>> proposal myself.
>> I will simply leave `checkedint` on DUB, and move on with my 
>> life.
>
> That is sensible, and a course of action I thought would 
> transpire. But I suggest you to reconsider. Your PR is a solid 
> implementation of the wrong idea. Before anyone gets offended, 
> let me add that I think there's a lot of good in that.

There is only one thing about all this that really offends me:

`checkedint` (and @burner's `SafeInt` before it) have been under 
development in the open for over a year now. There have been 
several discussions in the forums, with feedback being actively 
solicited. Significant design changes were made to address 
various people's needs. `SafeInt` was an open pull request for 
many months with 100+ comments accumulating in that time.

Why didn't you make your design requirements known at any earlier 
point in this process? If you are ultimate gate keeper for Phobos 
(as you seem to be), you ought to make your requirements known 
*before* the implementation is finished.

Even so, I'm not particularly upset. I've learned a great deal 
through this project, and `checkedint` will still be available 
for anyone who wants to use it through DUB.

The code is Boost Licensed, so anyone who wants to is free to 
fork it and try to fulfill your vision.

> For this kind of work (not algorithm-intensive) ideas are 
> cheap; the solid implementation matters a lot more than the 
> idea - the same expertise can be put to use on another idea.
>
> I tried to offer a careful review by a competent peer, with an 
> eye for taking an okay design toward a great design. The kind 
> of review I wish to get now as much as at any point of my 
> career. They are difficult to receive but often have a lot of 
> potential in them.

I don't mind a scathing review, so long as it has been properly 
researched and thought through. I do object to being criticized 
for not including features that no one asked me for until now, 
and which have little to do with the original purpose of the 
project, though.

>> So, I'm putting out a general call now for the community to 
>> download the
>> DUB package, try actually *using* it for something, and speak 
>> up as to
>> whether the design seems good, or not.
>>
>> If the decision is made to accept the high-level design, then 
>> we can go
>> back to bikeshedding about names, fixing typos, 
>> tweaking/trimming the
>> API, etc.
>
> I don't think checkedint in a form close to its current one is 
> for Phobos. I would argue it's not for D. Starting with the 
> problem statement "we want to check integral operations for 
> overflow and other surprising behaviors" and ending with 4.5 
> KLOC defining a bunch of names in 6 modules makes it highly 
> suspicious there is an overgrown underbelly somewhere. The 
> language features are not orchestrated properly. Even if it 
> were the case that there's no smaller design that conforms with 
> the requirements, that means requirements have a problem.
>
>
> Andrei

I believe a fundamental part of the problem, is that something 
like `SmartInt` should be built in to the language as the default 
integer type, not tacked on as a library. (Stuff like bound types 
would still be implemented in the library.)

However, my understanding is that this approach was reject by 
Walter Bright about two years ago (and obviously actually making 
it default would involve unacceptable breakage at this point). 
So, I tried to work with what we have.