DIP 1016--ref T accepts r-values--Formal Assessment

[Manu]

On Thu, Jan 24, 2019 at 11:35 PM Walter Bright via
Digitalmars-d-announce <digitalmars-d-announce at puremagic.com> wrote:
>
> No, it is not rejected in principle. Finding serious errors in it on the eve of
> approval is disappointing, and is not auspicious for being in a hurry to approve it.

I'm very clearly NOT in a hurry here. We've been sitting on this for 10 years.
What's weird is that you closed the door on iteration, and instead
suggested I should write a new one with someone competent.

More strangely, part of your feedback is broken, it appears you've
reviewed and made assessment against code and text that's just not
there, and you've neglected to respond to those points several times
now.
The error you found seems entirely revision-worthy rather than
rejection-worthy. Your comments about treating expressions as
statements is just wrong, and from that point on where you've
mis-interpreted something so fundamental to the DIP, I don't think
it's possible to trust any outcome from your 'formal assessment'.

I appreciate that you identified the exception issue, we'll fix it,
but I think you need to reconsider the formal rejection.

> but it is a bit unfair to the
> implementor to dump an incomplete spec on him and have him fill in the gaps

How is that the intent? We can get the rewrite semantics right with an
iteration.
So is it rejected on that premise? I don't understand how re-reading
it with satisfactory rewrite logic going to change your assessment of
the DIP in general? No surrounding text would change, and assuming
that the rewrite is corrected, then do you just find a different
reason to reject it?
If so, then that needs to be the reason for the rejection, and not the
error in the rewrite.

I presume the real reason for rejection is this part:
"They say that with the current semantics, this function only operates
on long values as it should. With the proposed semantics, the call
will accept all shared integral types. Any similar proposal must
address this hole in order to be accepted."

But to make that criticism is to miss the point entirely. The point is
to do the thing you say needs to be addressed... and a whole bunch of
techniques to motivate the compiler to emit desirable compile errors
can be deployed in various circumstances. None of them are
particularly unpleasant or awkward.
TL;DR: use `out`, use `*`, use @disable, use const. These can and
should all be deployed appropriately anyway.

Is that the reason it was rejected? If so, then I can't fix that by
rewriting the DIP, that *is* the DIP.
If you're not persuaded by the advantages, and that (rather extensive)
set of tools to mitigate the side effects you're concerned about, then
that's really more of an opinion than a technical rejection.
I guess you're entitled to say "I don't like it, and I reject it
because I don't like it", but you have to *say* that, and not make up
some other stuff.

> The statement thing is a "do what I meant, not what I wrote" example, and DIPs need
> to be better than that. You're leaving him to design where the temporaries go,
> where the gates go, and ensure everything is properly exception safe.

I agree, we'll fix the temporaries; but getting that correct is a
revision surely. There's no spec to change there.
The criticism talking about rewriting expressions as statements is
still mysterious to me. I don't understand how a rejection can be
presented based on an incorrect reading of the DIP... and how am I
supposed to accept the rejection text containing those criticisms when
the criticisms don't address what's written?
You had to change the code (removing the semicolon from the statement)
to make the claim that I was rewriting expressions as statements, and
I honestly have no idea why you did that?

Anyway...