DIP 1018--The Copy Constructor--Formal Review

Walter Bright newshound2 at digitalmars.com
Sun Feb 24 21:22:33 UTC 2019


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.



More information about the Digitalmars-d-announce mailing list