DIP 1018--The Copy Constructor--Formal Review

[Manu]

On Mon, Feb 25, 2019 at 3:10 PM Olivier FAURE via
Digitalmars-d-announce <digitalmars-d-announce at puremagic.com> wrote:
>
> On Monday, 25 February 2019 at 16:00:54 UTC, Andrei Alexandrescu
> wrote:
> > Thorough feedback has been given, likely more so than for any
> > other submission. A summary for the recommended steps to take
> > can be found here:
> >
> > https://forum.dlang.org/post/q2u429$1cmg$1@digitalmars.com
> >
> > It is not desirable to demand reviewers to do more work on the
> > review or to defend it. Acceptance by bullying is unlikely to
> > create good results. The target of work is squarely the
> > proposal itself.
>
> Agreed.
>
> Honestly, I am not impressed with the behavior of several members
> here.
>
> I understand that the rvalue DIP went through a long process,
> that some people really wanted it to be accepted, and that it was
> frustrating to wait so long only for it to be refused, but at
> some point, you guys have to accept that the people in charge
> refused it.

No, you've missed the point **completely**.
I'm not even remotely surprised it was rejected, I never imagined that
I'd change peoples minds on this after trying to do so for 10 years
running.

> They explained why they did, their reasons matched
> concerns other users had, and they explained how to move the
> proposal forward.

This sentence couldn't be more wrong.

I'm going to write this again because you prompted me to, I've said it
elsewhere lots, but apparently you've missed it;
What pissed me off was that the rejection text was almost completely
wrong, it almost felt like they just skimmed it and made up details
according to presumption, and then when I raised the topic on what was
actually wrong looking for actionable feedback, it was made clear that
it was not open to amendment, I *must* write a whole new DIP and
completely reboot the process because all the text was rubbish, and I
should employ someone else competent to do it with me. Then I was
insulted a couple more times; it was implied that the DIP was so bad I
didn't even understand the implications of my own text (I did), and
that it had holes large enough to drive a truck through (it
doesn't)... and only then after a few cycles of referring to the
*actual* text that was written, it was conceded that those criticisms
were indeed incorrect, and then we were able to arrive at some useful
feedback, all of which is of trivial-amendment magnitude; fix the
rewrite to address exceptions, and add some additional text to clarify
a point of misunderstanding that I thought I couldn't have made more
clear if I tried.
Even at the tail end of that though, the result remained the same:
rewrite the DIP, reboot the process, another few hundred days later...
it was expressly rejected that an amendment would be accepted for
consideration, despite agreeing at the end of the thread that that's
all that's required to address the *true* criticisms.

That was a worthless experience, and it didn't help anyone.

> So again, I get that this is frustrating, but repeatedly
> complaining and asking for an appeal and protesting about other
> DIPs being accepted is *not* professional behavior.

I'm not a bloody professional, I'm a volunteer!
I do think it would have been useful to amend the rejection text to be
true at the very least, and match the proposal that is written.
I held that position before the thread had played out to where useful
action points emerged, simply because I wanted to have any idea how to
move forward. At the conclusion of that thread, we have the data, and
I don't care, although still no path to have it reconsidered with
amendments, and I'm not gonna take a few hundred more days to start
over.

The reason I bring it up here is not that I'm salty (I am), but
because I'm literally astonished that it's been agreed it's fine that
a copy constructor can mutate the source... and I can't help but draw
contrast to the exact same sorts of arguments that people were using
to break my DIP, and countless other proposals that I've seen over the
years. My DIP was just one of very very many instances of where this
class of issue (unexpected mutation of caller-owned data) would be
used to destroy something, but we're accepting it here at a very
fundamental level of the language.
I just can't see how it's fine in this case, after being show-stopping
for as long as I've been watching.

And to circle right back to the start; I suspect the only reason that
it's considered acceptable here, is that this is an issue of extremely
high importance, and nobody has any better ideas.
To repeat my comment; the problem as I see it, is that `const` as
defined is extremely problematic, and rather than address that hard
issue, we'll just make a compromise in this case.

Anyway, I actually support this DIP, I'm for practical solutions to
problems... the only point I was trying to make at the start of this
thread is that this sets a precedent, which if we're fair, requires a
re-examination of so many rejected ideas gone by.