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.
