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