Walter and Andrei have requested the Final Review round be dropped for DIP 1018, "The Copy Constructor", and have given it their formal approval. They consider copy constructors a critical feature for the language.

Walter provided feedback on Razvan's implementation. When it reached a state with which he was satisfied, he gave the green light for acceptance.

The DIP:
https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1018.md


The implementation:
https://github.com/dlang/dmd/pull/8688

On Sunday, 24 February 2019 at 10:46:37 UTC, Mike Parker wrote:
> Walter provided feedback on Razvan's implementation. When it reached a state with which he was satisfied, he gave the green light for acceptance.
>
> The DIP:
> https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1018.md

Yay! Congrats to Razvan. Was this a roadblock towards reference counting, or am I confused?

On 24.02.19 11:46, Mike Parker wrote:
> Walter provided feedback on Razvan's implementation. When it reached a state with which he was satisfied, he gave the green light for acceptance.

Sounds like it might be a "worst acceptable proposal" [1] which Andrei says the DIP process is supposed to avoid.


[1] https://forum.dlang.org/post/q2ndr8$15gm$1@digitalmars.com

On Sunday, 24 February 2019 at 12:57:06 UTC, ag0aep6g wrote:
> On 24.02.19 11:46, Mike Parker wrote:
>> Walter provided feedback on Razvan's implementation. When it reached a state with which he was satisfied, he gave the green light for acceptance.
>
> Sounds like it might be a "worst acceptable proposal" [1] which Andrei says the DIP process is supposed to avoid.
>
>
> [1] https://forum.dlang.org/post/q2ndr8$15gm$1@digitalmars.com

If I'm understanding correctly, Andrei said that about the proposals, while Walter gave feedback on the implementation, which is a little different.

But yeah, the proposal was clearly fast-tracked, probably because it's needed for reference counting and better C++ integration.

On Sun, Feb 24, 2019 at 2:50 AM Mike Parker via Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote:
>
> Walter and Andrei have requested the Final Review round be dropped for DIP 1018, "The Copy Constructor", and have given it their formal approval. They consider copy constructors a critical feature for the language.
>
> Walter provided feedback on Razvan's implementation. When it reached a state with which he was satisfied, he gave the green light for acceptance.
>
> The DIP: https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1018.md
>
>
> The implementation:
> https://github.com/dlang/dmd/pull/8688

I mean like, my DIP was almost violently rejected, 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"...

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. 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"

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.

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, and I thought you were going to rewrite it. Was I mistaken?


> 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++.


> 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.


> 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.


> 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.

On 2/24/2019 1:02 PM, Manu wrote:
> 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.

On Sun, Feb 24, 2019 at 1:25 PM Walter Bright via Digitalmars-d-announce <digitalmars-d-announce@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.

Thanks for letting me know you're abandoning the rvalue ref DIP. I had held off working on it because I didn't want to duplicate efforts; we're short-staffed enough as it is.

The problem with C++ const is it only goes one level, i.e. what I call "head-const". If you pass a T to a const parameter, anything T references remains mutable. It's more of a suggestion than anything reliable or enforceable. It only works if your data structures are simple aggregates, not graphs.

D's const has teeth. Nothing can be modified through T. If you're used to writing code that tweaks const data under the hood, D's const will never work for you. Yes, it means rethinking how the data and code is organized, and that can be painful. But it is how FP works. FP offers a number of advantages, and D's const offers a path into that.

For example, most of DMD is written in the C++ style where functions frequently are written to both return some information *and* tweak the data structure. This does not work with const. It needs to be reorganized so that getting information about a data structure is separated from modifying the data structure. I've made such changes in a few places in DMD, and have been very pleased with the results - the code is much easier to understand.

To sum up, you're quite right that you cannot write C++ style code using D const. It hast to be in a much more FP style. If you're not accustomed with FP style, this can be a difficult learning process. I know this from firsthand experience :-)

For me the only real annoyance with const is I often cannot use "single assignment" style declarations with pointers:

I.e.:

    const int* p = &x;
    p = &y; // error, good
    *p = 4; // also error, not what I wished

This C++ const does provide, and it's good, but it's not really worth that much.