DIP 1018--The Copy Constructor--Formal Review

[Manu]

On Sun, Feb 24, 2019 at 1:25 PM Walter Bright via
Digitalmars-d-announce <digitalmars-d-announce at puremagic.com> wrote:
>
> On 2/24/2019 1:02 PM, Manu wrote:
> > I mean like, my DIP was almost violently rejected,
>
> I thought it was clear what was needed to be done with it,

To be fair, initial criticism was 75% just plain wrong (like the text
wasn't even read properly, with no request for clarifications), and
100% unproductive.
True actionable criticisms became clear only after quite a laborious
and somewhat insulting series of exchanges.

> and I thought you were going to rewrite it. Was I mistaken?

It's not on my short list. I don't really even wanna look at it at
this point, my motivation couldn't be more depleted. There's no part
of me that has any desire to re-engage that process right now.
I'd encourage anybody else to take it and run though. It's still my #1
frustration... it's not getting less annoying!

Incidentally, the key problems that upset people about my proposal,
and probably the reason it wasn't that way from the very start are all
predicated on this same `const` issue.

> > but in here there's text like this:
> >
> > "The parameter of the copy constructor is passed by a mutable
> > reference to the source object. This means that a call to the copy
> > constructor may legally modify the source object:"
> >
> > I can't see how that could be seen in any way other than what might
> > reasonably be described as "a hole large enough to drive a truck
> > through"...
>
> What's the hole? BTW, the D copy-ctor semantics are nearly identical to that of C++.

Mutable copy-from argument is one of the same arguments people made
against my DIP, except about 100x worse being a live object owned by
someone else that may be undesirably mutated, rather than an expiring
rvalue that nobody will ever see again.

I'm mostly just amazed that the same bunch of minds that historically
take such strong issue with this sort of thing can find that it's okay
in this case...
I can't imagine a more concerning case of this class of problem being
manifest, but in this case, we've judged that it's fine?

If this is acceptable now, then I think it's in order that we comb
back over decades of other rejected opportunities and revisit them
with this precedent.

> > But anyway, that's pretty wild. I think there's a clear pattern we've
> > been seeing here with practically every lifetime management DIP, and
> > also in general for forever, is that D's `const` just fundamentally
> > doesn't work.
>
> I don't see what const has to do with lifetime management. For example, it is
> irrelevant to dip25 and dip1000.

I say lifetime *management*; I feel copying/moving and friends are an
associated part of lifetime management beyond just tracking ownership.
Construction/destruction are features of lifetime management in my
brain.
We've had const problems with copying and constructors forever,
including this DIP, and the problems that this DIP exists for to
address.

> > Couple this with the prevailing wisdom which is to
> > recommend that people "don't use const, because you can't write
> > programs and use const"
>
> That is true for writing C++ style code. D const is much more in line with FP
> programming style.

It's true for writing D style code; most D-style code is not FP
code... at best, a few call-trees at the leaves of the application.
The overwhelming recommendation I see posted very frequently in the
forum is "don't use const", and the nature of all the articles I've
read on the topic as the years progress are moving towards a more
clearly stated and unashamed position of "don't use const".

I understand the narrow use case where it can be applicable to FP
style programming, but it comes up quite infrequently as an
opportunity, and attempts are often met with a rude awakening at some
point that you work far enough into your project that the fantasy of
your flawless design start to break while true details of the program
structure begin to emerge.

Almost every attempt I've made to try and use D's const effectively
has failed at some point down the path as I reach some level of
complexity where the program structure has relationships that start to
look like a graph. It just naturally occurs that data in a const
structure may point back to the outer non-const world again, and
that's totally *fine* structurally and intellectually, it's just that
D can't express it.

You basically have 2 options when this inevitably emerges; you sweep
your code removing const from a lot of things (which sadly highlights
a whole lot of wasted energy in doing so, and in your foolishly trying
in the first place), or you make some HeadConst!(T) thing which casts
const away, whereby you deploy UB and a quiet prayer that the compiler
doesn't do anything bad.

I've tried to defend D's const for a very long time, but the reality
is that every sufficiently complex program I've written has seen my
attempts with const fail at some level of complexity, and the forum
repeats the wisdom "yeah, don't use const, n00b!".
There's endless conversations and blog posts about it; Jonathan wrote
one I read recently. You know this is a thing.

So the opinion I've arrived at is; WHY? What is D's const for? I don't
really know.
The real-world honest-to-god practical reality of D's const is that
it's just a nuisance that tickles a part of your brain that wants to
write "correct" code, teases you for a little while when you struggle
with it, and then mocks your feeble failure when you relent and remove
`const` from your code again.
I've yielded to the chorus; don't use const... at which point you
really have to wonder; what is D's const for?

C++ const is a valid form of const, and it's undeniably more useful.
Is there a way we could express both possibilities in the language?
Maybe? I dunno. If I had to choose just one, the evidence has been
gathered.

> > I think we need to throw in the towel, C++'s const is right, and D's
> > const is just wrong, and no amount of pretending that's not true will
> > resolve the endless stream of issues.
> > Where's the DIP to migrate to C++-style const? That is the predicate
> > for basically every important development I've seen lately...
> > including this one.
>
> If you want a DIP, write one! But I suggest the rvalue ref one first.

Nar, my tank is empty. I'm kinda done.
My STL work is blocked on various stuff, I consistently fail to move
with satisfying velocity:
 - I've encountered containers with interior pointers which can't
move, so they're doomed until we have a path forward on that.
 - inline's broke, which adds upsetting friction to higher-level
support functionality
   * and for some reason I seem to have to argue that case too, which
I don't have the patience for.

With emplace in druntime I can move forward a little, but opening that
can of worms kinda made me upset that many core language-level traits
are in phobos (and privately mirrored in druntime), and I feel like I
need to try and untangle that... >_<

> > I mean like, my DIP was almost violently rejected,
>
> If it makes you feel any better, Razvan had to endure major rewrites of both the
> dip and the implementation.

It's not that it was rejected; it's that it was rejected without even
having been read properly, no clarifications requested, no useful
feedback given with the rejection, and the little feedback offered
being outright wrong. Then upon being upset about that and objecting
to the response text as invalid, I had my intellect/understanding of
the problem space mocked a few times before conversation eventually
arrived at some actionable points.

I hope you didn't do that to him too! That wouldn't want to be
standard operating procedure.
Good on him for saicking it through, he's a bigger man than me... but
the const thing's still not really okay.