www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - DIP 1018--The Copy Constructor--Formal Review

reply Mike Parker <aldacron gmail.com> writes:
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
Feb 24 2019
next sibling parent Bastiaan Veelo <Bastiaan Veelo.net> writes:
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?
Feb 24 2019
prev sibling next sibling parent reply ag0aep6g <anonymous example.com> writes:
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
Feb 24 2019
parent Olivier FAURE <couteaubleu gmail.com> writes:
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.
Feb 24 2019
prev sibling next sibling parent reply Manu <turkeyman gmail.com> writes:
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.
Feb 24 2019
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Feb 24 2019
next sibling parent reply Manu <turkeyman gmail.com> writes:
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.

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.
Feb 24 2019
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Feb 24 2019
parent reply Manu <turkeyman gmail.com> writes:
On Sun, Feb 24, 2019 at 4:25 PM Walter Bright via
Digitalmars-d-announce <digitalmars-d-announce puremagic.com> wrote:

 Thanks for letting me know you're abandoning the rvalue ref DIP.


It's not an "rvalue ref" DIP (which I think has confused a lot of
people), it's an rvalue *by-ref* DIP.
In my head, an "rvalue ref" DIP is something completely different,
useful for implementing move semantics of mismatching types.

Are you talking about my DIP or that other thing?


 I had held off
 working on it because I didn't want to duplicate efforts; we're short-staffed
 enough as it is.


'abandoning's a strong word, but I don't have motivation to work on it
right now. Please, be my guest!
Feb 24 2019
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Your DIP, and nobody else is going to do it, so it falls to me.

BTW, everyone should expect the DIP process to be brutal. It has to be, we're 
long past the stage where we can allow misshapen stuff to get into the
language. 
Nobody was very kind with my bottom type DIP :-)

You should read the dismissal of mine and Andrei's "static if" proposal for
C++! 
(Ironically, it was later adopted after someone else redid it, after removing 
one of its keystone features.)
Feb 24 2019
parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Monday, 25 February 2019 at 02:56:13 UTC, Walter Bright wrote:

 Your DIP, and nobody else is going to do it, so it falls to me.


It will be reviewed at Dconf, please make sure you have an 
_accurate_ summary of your criticisms of the DIP ready for then.


 BTW, everyone should expect the DIP process to be brutal.


No! It should be thorough, that is a critical distinction.


 It has to be, we're long past the stage where we can allow 
 misshapen stuff to get into the language. Nobody was very kind 
 with my bottom type DIP :-)


Perhaps because you responded to _precisely none_ of the feedback 
and wasted everybody's time?


 You should read the dismissal of mine and Andrei's "static if" 
 proposal for C++! (Ironically, it was later adopted after 
 someone else redid it, after removing one of its keystone 
 features.)


I have, it is hysterical in all senses to the word. I don't see 
how that relates to any of this.
Feb 24 2019
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.com> writes:
On 2/25/19 1:06 AM, Nicholas Wilson wrote:

 On Monday, 25 February 2019 at 02:56:13 UTC, Walter Bright wrote:

 Your DIP, and nobody else is going to do it, so it falls to me.


 
 It will be reviewed at Dconf, please make sure you have an _accurate_ 
 summary of your criticisms of the DIP ready for then.


This seems to be a misunderstanding of protocol. A negative review is 
simply a signal that the submission has not been strong enough. As such, 
the submission, not the review, needs to be improved. There are 
similarities and differences between our DIP process and paper 
submission reviews at conferences and journals everywhere; one key 
similarity is that the submitters are on hook for providing convincing 
submissions, whereas reviewers are not required to defend their reviews. 
It's an asymmetric relationship that occasionally frustrates, but it is 
as such for good reason and it works.

It does happen in such processes that a submission is rejected wrongly, 
by means of reviews that do not reflect the quality of the submission. 
This is the case most often when a nonspecialist reviews a specialty 
paper and fails to appreciate the subtler aspects of the submission. In 
this DIP's case, we submit this is not the case here; to the extent the 
DIP failed to convey its intent, that is squarely a pervasive matter 
with the DIP itself. It is not a matter of misunderstanding 1-2 
sentences, but a problem of precision in specification that needs to be 
approached with due care.

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.

Our understanding after Manu asked for action items was that he would be 
up for the work in short order. Not wanting to step on any toes and seem 
like taking away credit, Walter decided to hold off on working on it 
although he wanted to do so now that the matter is in his hands. Now 
that after three weeks Manu gave permission, I assume Walter would be up 
for the task.


Andrei
Feb 25 2019
next sibling parent reply Olivier FAURE <couteaubleu gmail.com> writes:
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. They explained why they did, their reasons matched 
concerns other users had, and they explained how to move the 
proposal forward.

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. Reviewers are 
entitled to refuse contributions for any reasons, and if a 
reviewer rejects a proposal, too bad; you don't get to ask again 
and again and complain and bring it up in every other thread 
until they say yes.

Yes, this DIP was fast-tracked. Yes, this can feel unfair. And 
yet, it makes sense that it was fast-tracked, because it fits a 
priority of the project owners (C++ interoperability + reference 
counting) and project owners are allowed to have priorities. It's 
not like this DIP was rushed or has major vulnerabilities (the 
"mutable copy constructor" thing is necessary for reference 
counting).
Feb 25 2019
next sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Monday, February 25, 2019 4:09:55 PM MST Olivier FAURE via Digitalmars-d-
announce wrote:

 Yes, this DIP was fast-tracked. Yes, this can feel unfair. And
 yet, it makes sense that it was fast-tracked, because it fits a
 priority of the project owners (C++ interoperability + reference
 counting) and project owners are allowed to have priorities. It's
 not like this DIP was rushed or has major vulnerabilities (the
 "mutable copy constructor" thing is necessary for reference
 counting).


It's worth noting that the copy constructor DIP went through a _lot_ of
discussion and was revised accordingly. So, while Walter and Andrei may have
considered it a priority, it still took a while for it to get to the point
that it was acceptable.

- Jonathan M Davis
Feb 25 2019
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/25/19 6:09 PM, Olivier FAURE wrote:

 Yes, this DIP was fast-tracked. Yes, this can feel unfair. And yet, it 
 makes sense that it was fast-tracked, because it fits a priority of the 
 project owners (C++ interoperability + reference counting) and project 
 owners are allowed to have priorities. It's not like this DIP was rushed 
 or has major vulnerabilities (the "mutable copy constructor" thing is 
 necessary for reference counting).


I haven't heard the final decision from Walter yet, but I proposed that 
in the interest of quality, we will go through the customary two weeks 
reviews with DIP 1018.
Feb 25 2019
parent Walter Bright <newshound2 digitalmars.com> writes:
On 2/25/2019 6:26 PM, Andrei Alexandrescu wrote:

 I haven't heard the final decision from Walter yet, but I proposed that in the 
 interest of quality, we will go through the customary two weeks reviews with
DIP 
 1018.


I approved it.
Feb 25 2019
prev sibling next sibling parent reply Manu <turkeyman gmail.com> writes:
On Mon, Feb 25, 2019 at 3:10 PM Olivier FAURE via
Digitalmars-d-announce <digitalmars-d-announce 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.
Feb 25 2019
next sibling parent reply Donald <donald gmail.com> writes:
On Tuesday, 26 February 2019 at 03:17:53 UTC, Manu wrote:

 ...


It's funny that you keep wasting time posting/replying instead of 
fixing your DIP.

By the way like the other guy, I found disrespectful (With 
RazvanN7) use this topic as argument for your rejected DIP, 
instead to debate about what this one has to offer.

Donald.
Feb 25 2019
parent Manu <turkeyman gmail.com> writes:
On Mon, Feb 25, 2019 at 8:10 PM Donald via Digitalmars-d-announce
<digitalmars-d-announce puremagic.com> wrote:

 On Tuesday, 26 February 2019 at 03:17:53 UTC, Manu wrote:

 ...


 It's funny that you keep wasting time posting/replying instead of
 fixing your DIP.


An hour typing rubbish on the forum is nothing compared to rebooting
hundreds of days waiting on the review pipeline!


 By the way like the other guy, I found disrespectful (With
 RazvanN7) use this topic as argument for your rejected DIP,
 instead to debate about what this one has to offer.


I didn't do that, I raised an issue about const fundamentally, and
used my DIP to contrast the weird decision relating to const.
My post is a post about const. I then started replying to other
peoples responses along the way.
Feb 25 2019
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 2/25/2019 7:17 PM, Manu wrote:

 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,


Mutating the lvalue ref was not the issue, as I recall. It was conversion of
the 
value to a temporary of a different type, then modifying the temporary, not the 
original.

https://digitalmars.com/d/archives/digitalmars/D/announce/DIP_1016--ref_T_accepts_r-values--Formal_Assessment_54145.html#N54345

It is not analogous to the mutable cpctor argument case, because there is no 
hidden conversion to a temporary.
Feb 25 2019
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/25/2019 7:17 PM, Manu wrote:

 break my DIP


The review process is not about "why not add this feature" , but "why should we 
have this feature".

Additionally, it is most assuredly about finding flaws in it. Isn't it best to 
find out the flaws before going further with it than finding them in the field?

As I mentioned before, it's supposed to be brutal. Any 
testing/certification/review process is about trying to break it.

It has (hopefully) nothing to do with how hard (or little) you worked on it,
nor 
the cut of your jib, nor acceptance (or not) of mediocrity/merit in other DIPs.
Feb 25 2019
parent reply Manu <turkeyman gmail.com> writes:
On Mon, Feb 25, 2019 at 9:30 PM Walter Bright via
Digitalmars-d-announce <digitalmars-d-announce puremagic.com> wrote:

 On 2/25/2019 7:17 PM, Manu wrote:

 break my DIP


 The review process is not about "why not add this feature" , but "why should we
 have this feature".

 Additionally, it is most assuredly about finding flaws in it. Isn't it best to
 find out the flaws before going further with it than finding them in the field?

 As I mentioned before, it's supposed to be brutal. Any
 testing/certification/review process is about trying to break it.

 It has (hopefully) nothing to do with how hard (or little) you worked on it,
nor
 the cut of your jib, nor acceptance (or not) of mediocrity/merit in other DIPs.


I'm talking about this DIP. Allowing a mutable copy argument feels super weird.
The reasons are clear, but that doesn't make it feel less weird.
I feel like the problem is with const, not with this DIP, but I'm not
about to convince anybody, so we're all good here.
Feb 25 2019
parent Kagamin <spam here.lot> writes:
On Tuesday, 26 February 2019 at 05:38:01 UTC, Manu wrote:

 I'm talking about this DIP. Allowing a mutable copy argument 
 feels super weird.


The problem was out of place mutation, which can't happen with 
copy constructor, because initialization from rvalue is a move, 
so the copy constructor won't be called.
Feb 27 2019
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 2/25/2019 3:09 PM, Olivier FAURE wrote:

 Yes, this DIP was fast-tracked. Yes, this can feel unfair. And yet, it makes 
 sense that it was fast-tracked, because it fits a priority of the project
owners 
 (C++ interoperability + reference counting) and project owners are allowed to 
 have priorities. It's not like this DIP was rushed or has major
vulnerabilities 
 (the "mutable copy constructor" thing is necessary for reference counting).


And yes, it underwent major rewrites as Razvan can confirm :-)
Feb 25 2019
prev sibling parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Monday, 25 February 2019 at 16:00:54 UTC, Andrei Alexandrescu 
wrote:

 On 2/25/19 1:06 AM, Nicholas Wilson wrote:

 On Monday, 25 February 2019 at 02:56:13 UTC, Walter Bright 
 wrote:

 Your DIP, and nobody else is going to do it, so it falls to 
 me.


 
 It will be reviewed at Dconf, please make sure you have an 
 _accurate_ summary of your criticisms of the DIP ready for 
 then.


 This seems to be a misunderstanding of protocol. A negative 
 review is simply a signal that the submission has not been 
 strong enough. As such, the submission, not the review, needs 
 to be improved.


I'm not suggesting that the DIP is perfect, nor that it was 
without ambiguities and misunderstandings, nor that is 
can't/doesn't need to be improved.
What _is_ important is that the time spent on improving it 
covered that areas that actually need improvement, and given the 
misunderstandings on all sides, a useful starting point is the 
set of problems the reviewers have identified crosschecked by the 
authors. That is not an unreasonable request.


 There are similarities and differences between our DIP process 
 and paper submission reviews at conferences and journals 
 everywhere; one key similarity is that the submitters are on 
 hook for providing convincing submissions, whereas reviewers 
 are not required to defend their reviews. It's an asymmetric 
 relationship that occasionally frustrates, but it is as such 
 for good reason and it works.


I've said before that that comparison is weak and not 
particularly useful, irrespective of  its intention.


 It is not a matter of misunderstanding 1-2 sentences, but a 
 problem of precision in specification that needs to be 
 approached with due care.


I believe it is both, which is the basis for the opinion that 
resubmission is not the appropriate course of action to make best 
use of everyone's time.


 * Description of the typechecking process, with examples of 
 code that passes and code that fails;

 * A clarification that lowering proceeds not against all 
 expressions, but only against rvalues;
 
 * Several places in text in which it is explained that rvalues 
 resulted from implicit conversions are not eligible;

 * etc. etc. etc.


That is a good start, though I suspect that the list is not 
complete given the last item.


 It is not desirable to demand reviewers to do more work on the 
 review or to defend it.


On the contrary, if we believe your reasoning to be unsound or 
misguided (irrespective of who is at fault) then clarification 
and resolution are the only appropriate courses of action.


 Acceptance by bullying is unlikely to create good results.


I agree, but that has not happened here.


 The target of work is squarely the proposal itself.

 Our understanding after Manu asked for action items was that he 
 would be up for the work in short order.


The keyword here is "short". By suggesting that the action 
required is to rewrite, the order is most definitely not short. 
Time is a valuable resource, and a new DIP from scratch through 
the DIP process takes a lot of it.
Feb 25 2019
next sibling parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Tuesday, 26 February 2019 at 00:23:19 UTC, Nicholas Wilson 
wrote:

 On Monday, 25 February 2019 at 16:00:54 UTC, Andrei 
 Alexandrescu wrote:

 * etc. etc. etc.


 That is a good start, though I suspect that the list is not 
 complete given the last item.


Oh, it keeps going.
Feb 25 2019
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/25/19 7:23 PM, Nicholas Wilson wrote:

 There are similarities and differences between our DIP process and 
 paper submission reviews at conferences and journals everywhere; one 
 key similarity is that the submitters are on hook for providing 
 convincing submissions, whereas reviewers are not required to defend 
 their reviews. It's an asymmetric relationship that occasionally 
 frustrates, but it is as such for good reason and it works.


 
 I've said before that that comparison is weak and not particularly 
 useful, irrespective of  its intention.


That you've said it before does not make it any more correct. We have 
intently modeled the acceptance process after that used by the review 
process used by conferences, journals, and standardization committees - 
naturally from the communities I have some familiarity with (Programming 
Languages, Machine Learning, Natural Language Processing, Algorithms, 
ISO C++). So the alleged similarities are more of a statement of fact 
than a metaphor.

There are differences, too, of which the public discussions in this 
forum is the main one. This is in danger of getting abused; open 
discussions around DIPs in this forum give the false impression that DIP 
authors have the authority to demand any extent of explanation and 
justification of a decision. We do not have the capacity to do that, and 
it would not be anymore appropriate than journal reviewers being 
required to provide detailed feedback to submitters' satisfaction. This 
whole notion of a meeting whereby Walter is grilled by a committee on 
why exactly he rejected DIP 1016 is Kafkaesque.


 The keyword here is "short". By suggesting that the action required is 
 to rewrite, the order is most definitely not short. Time is a valuable 
 resource, and a new DIP from scratch through the DIP process takes a lot 
 of it.


You can count on me to massage the bureaucracy out of the process if 
that's the bottleneck. The most significant bit is to focus on working 
together toward making the proposal better, as opposed to focusing on 
negotiating acceptance. But whether the DIP keeps the number or gets 
another one, if the revised document is a 95% cut and paste of the 
existing one, the review is liable to be a 95% cut and paste of the 
existing one.
Feb 25 2019
parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Tuesday, 26 February 2019 at 02:51:54 UTC, Andrei Alexandrescu 
wrote:

 On 2/25/19 7:23 PM, Nicholas Wilson wrote:

 I've said before that that comparison is weak and not 
 particularly useful, irrespective of  its intention.


 That you've said it before does not make it any more correct.


You're right that is does't change the facts, thats why it is an 
opinion. The resemblance, if any, it bears to the processes you 
describe is completely beside the actual point: namely that it is 
not _useful_.


 There are differences, too, of which the public discussions in 
 this forum is the main one.


Yes, thats why I think the journal submission metaphor is not apt.


 This is in danger of getting abused; open discussions around 
 DIPs in this forum give the false impression that DIP authors 
 have the authority to demand any extent of explanation and 
 justification of a decision.


Quoting myself from above:

 On the contrary, if we believe your reasoning to be unsound or 
 misguided
 (irrespective of who is at fault) then clarification and 
 resolution are the only appropriate courses of action.


If you believe that constitutes abuse, I really don't know what 
to say.


 We do not have the capacity to do that, and it would not be 
 anymore appropriate than journal reviewers being required to 
 provide detailed feedback to submitters' satisfaction.


I sincerely hope you don't lack the capacity, else why are you 
reviewing it in the first place? Time or bandwidth, sure, thats 
what DConf Foundation meeting is for (among many other things).


 This whole notion of a meeting whereby Walter is grilled by a 
 committee on why exactly he rejected DIP 1016 is Kafkaesque.


Indeed, that would serve no purpose. What I want from such a 
meeting is:
1) an outline of requested changes that accurately reflects the 
sentiments of the DIP. I am fully aware the DIP underspecified 
and omitted some key aspects and that there were some ambiguities 
present. You have provided some in that link, thank you. Although 
I note that some of the advice is outdated/wrong. All this back 
and forth cements my growing suspicion that the forum is not an 
appropriate place for such discussions, it severely lacks 
bandwidth and reciprocal latency.

2) changes to the DIP process, i.e. what to do in the event of 
DIP breaking behaviour/ambiguities discovered post final review, 
so that these misunderstandings do not happen again.


 You can count on me to massage the bureaucracy out of the 
 process if that's the bottleneck.


Good, but this one is stuck until DConf, the forum (as a place of 
communication) lacks the bandwidth for this.


 The most significant bit is to focus on working together toward 
 making the proposal better, as opposed to focusing on 
 negotiating acceptance.


YES! Thats what we've been trying to do! How ever, we can't do 
that if the criticisms do not reflect reality (lowering to 
statements, which was given as an example in the DIP and wrongly 
characterised in the formal assessment) and the ones that are 
legitimate criticisms are scattered about the forum. Hence why we 
want the official reasons for rejection at the bottom of the DIP 
to be updated to reflect that.


 But whether the DIP keeps the number or gets another one, if 
 the revised document is a 95% cut and paste of the existing 
 one, the review is liable to be a 95% cut and paste of the 
 existing one.


You, of all people, should know that a proposal is not a linear 
function of its text.
I _sincerely_ hope that your reviews aren't.
Feb 25 2019
prev sibling parent Greatsam4sure <greatsam4sure gmail.com> writes:
On Monday, 25 February 2019 at 02:29:40 UTC, Manu wrote:

 On Sun, Feb 24, 2019 at 4:25 PM Walter Bright via 
 Digitalmars-d-announce <digitalmars-d-announce puremagic.com> 
 wrote:

 Thanks for letting me know you're abandoning the rvalue ref 
 DIP.


 It's not an "rvalue ref" DIP (which I think has confused a lot 
 of
 people), it's an rvalue *by-ref* DIP.
 In my head, an "rvalue ref" DIP is something completely 
 different,
 useful for implementing move semantics of mismatching types.

 Are you talking about my DIP or that other thing?


 I had held off
 working on it because I didn't want to duplicate efforts; 
 we're short-staffed
 enough as it is.


 'abandoning's a strong word, but I don't have motivation to 
 work on it right now. Please, be my guest!


The worth of man is not measure by where he stand when all things 
are going well but where he stands in the time of face of 
challenge.

Your dip has face significant challenge. It is just a test on 
your ability to forge ahead and get what you believe done in the 
face of challenges.

I will really have problem in taking you serious if you just 
abandon the dip. Pls rewrite the dip and let it be 50-50% win for 
all of us
Feb 26 2019
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Feb 24 2019
next sibling parent reply Manu <turkeyman gmail.com> writes:
On Sun, Feb 24, 2019 at 4:40 PM Walter Bright via
Digitalmars-d-announce <digitalmars-d-announce puremagic.com> wrote:

 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 :-)


I agree with these facts, but your case-study is narrow, and you have
to stop saying "C++ style", which it really isn't.
It's very much D-style... almost all D code is written this way.
It's in conflict with too many other patterns, and they're not "C++
patterns", they're very legitimate D patterns.

Function pointers and delegates are often incompatible with const;
practically any code with some sort of call-back behaviour, and
anything that forms *any form* of traversible network where you'd like
any part of it to const fails. I've never written a program that was a
perfect tree. A small feature library maybe, but not a program that
does anything interesting.

It's great that we can write FP-ish code in D, it's particularly
useful for narrow, self-contained tasks; it helps me intellectually
factor some potentially complex leaf-level call-trees out of the
program structure, and I appreciate when libraries take that form; it
helps them have a smaller footprint in the larger complex suite. But
const doesn't play into that much, and if that can't interact with
normal D code, which is most code, then it's just not a useful piece
of language.

The proposition that everyone start writing straight-up FP code in D
is unrealistic, and if they wanted that, they'd use Rust every time.
People are here because they don't want to write Rust.


 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.


Are you serious? You can't honestly say C++ const is worthless?
Especially in comparison to D's const, which is _actually_ almost
completely worthless.
It really doesn't make anything better, and there's a whole class of
troublesome language issues that emerge from it being defined this
way.
The way C++ defines const is such that const can be used, and you can
integrate that code with other code.

I mean it seriously where I say I've tried to defend D's const for as
long as I've used D, but I can't escape the plain and honest reality
that D's const is not useful for almost anything practical.
Even the way you describe it above is like indulging in a little bit
of fetish, and I understand that, I try that every time thinking "I'm
gonna get it right... this time for sure! What a cool guy I am!", but
that never works out beyond a very small scope. const with a narrow
scope is where it's least impactful.

Then to make matters worse, `const` is a combinatorial testing
nightmare; you write your code mostly without const (because
conventional wisdom), and then you try and call into your lib from
various contexts and it just doesn't work. You need to set-up heaps of
tests to try and prove out that your code is const-robust that are
very easy to miss otherwise.
Then someone else tries to use your code with their code which is
using const (attempting at least); I've seen lots of libraries where
it would have been possible to support const, at least to some extent,
but they just didn't because "don't use const", but the result is that
the client of that library can't use const in their own code because
the lib undermines their effort in some way.

I don't like this concept that a piece of library code 'supports'
const, but that's where we are.

None of this is issue with C++ const, because it's defined in a way
that's useful, but also sufficiently localised that it doesn't invade
users code outwards.

const undermines its own value far too often, and with the effect I
describe above where one author's dismissing of const cascaded
outwards, it seals its own fate.
D's const rarely helps anything, it's honestly just a shiny thing that
you waste time chasing, and then you lose, and then the community
reminds you not to use const. It's incompatible with D in a lot of
fundamental ways, and if you argue that everyone should stop writing D
code and start writing something a lot more like Rust code instead,
you gotta admit that's a self-defeating argument?

If you're honest with yourself, we recognise that after 15-20 years of
the sorts of recommendations you make above not taking effect in
real-world D code, you must admit it's an objective failure. I haven't
wanted to admit it for as long as I've defended it... but I think it's
indefensible.

Also, the scope of your experiment above is not based in practical reality.
You said something to this effect "I reworked a little bit of code in
DMD, and was happy with the result. It feels simpler". I can write a
little bit of const-correct code too, but you need to get back to us
when you've covered all of DMD. This is a compiler; almost a perfect
tree, one of the most structurally simple and uniform programs
imaginable. But people don't write compilers, they write gigantic
metropolis's of libraries and glue, by 10s or 100's of authors
collaborating against a ticking clock.
If there were reasonable patterns to make D const work, we would have
discovered them by now, and there would be articles on the matter.
Apparently they don't exist though, and as such, it's usefulness is
constraints to narrow call-trees, very close to the leaf of your
application, and remains incompatible with a lot of other core
language and patterns.

On Sun, Feb 24, 2019 at 4:40 PM Walter Bright via
Digitalmars-d-announce <digitalmars-d-announce puremagic.com> wrote:

 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.
Feb 24 2019
parent reply Walter Bright <newshound2 digitalmars.com> writes:
I agree with your point that C++ const can be used in a lot more places than D 
const. Absolutely true.

Missing from the post, however, is an explanation of what value C++ const 
semantics have. How does it:

1. make code easier to understand?
2. prevent common programming bugs?
3. help with multithreaded coding problems?
4. improve code generation?

I know technically what it does (after all, I implemented it), but its value 
escapes me.
Feb 24 2019
parent reply Manu <turkeyman gmail.com> writes:
On Sun, Feb 24, 2019 at 6:35 PM Walter Bright via
Digitalmars-d-announce <digitalmars-d-announce puremagic.com> wrote:

 I agree with your point that C++ const can be used in a lot more places than D
 const. Absolutely true.

 Missing from the post, however, is an explanation of what value C++ const
 semantics have. How does it:

 1. make code easier to understand?


const code is self documenting and protective against modification by
issuing the user helpful error messages.



 2. prevent common programming bugs?


You can't modify const data, for instance, a copy constructor can't
freely modify the source value...



 3. help with multithreaded coding problems?


This is a different conversation about `immutable` and `shared`.
`const` doesn't say anything about D's decisions relating to
thread-locality by default, which obviously still applies.

Maybe you're trying to argue that a const object which contains an
escape-pointer to mutable data may lead to races? But that's not the
case, because all data is thread-local in D, so there's no races on
the mutable data either way unless it's `shared`... and then we need
to refer back to the thread I created months ago where `shared` is
useless and broken, and we REALLY need to fix that. (that is; `shared`
must have NO READ OR WRITE ACCESS to data members, only shared
methods, otherwise it's completely hollow)



 4. improve code generation?


Not a lot. But this is a red-herring; D's const won't improve code
generation where it's not present in the code.
Contrary to C++, D has a much higher probability of seeing the whole
AST and not encountering opaque extern barriers, which means it would
be relatively easy for D to recognise that the const object contains
no pointers to mutable data (assessed recursively), and then enable
any such optimisations that const offers to D today.



 I know technically what it does (after all, I implemented it), but its value
 escapes me.


I mean, you speak as if `const` is a synonym for `mutable` in C++...
const things are const. It is however possible that they contain a
pointer that leads out of the const data back into the mutable world,
and that's *desirable* in a whole lot of circumstances. Take that
away, and we arrive where we are in D.

It's also easy to NOT have pointers to mutable data escaping const
objects; make them const too!
If you want to implement a semantic where the const-ness of a member
tracks the const-ness of the owner, maybe we can apply `inout` to
behave that way.
Assuming we apply rules similar to C++, it looks like:

  const(S) const_s; // const instance of S
  struct S
  {
    int* a; // becomes `int const(*)`
    const(int)* b; // const(int*)
    inout(int)* c; // becomes const(int*) (or immtable(int*), etc)
  }

Alternatively, if const were spec-ed similar to C++ const, it would be
very easy to implement TransitiveConst!T as a tool. By any of these
means, could deploy it deliberately instead of unwillingly.
Feb 24 2019
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/24/2019 8:04 PM, Manu wrote:

 1. make code easier to understand?


 
 const code is self documenting and protective against modification by
 issuing the user helpful error messages.


I've had many people tell me they mean transitive const when they use const in 
C++. That is not self documentation. Nor is it very helpful. The very fact that 
const code compiles in C++ and surprises people when it doesn't compile in D 
shows the misunderstanding it engenders in C++ code. People infer that it is 
transitive when it is not.

Really, of what value is it to know that only the head can't be changed, with
no 
information about the rest?

An interesting manifestation of this uselessness in C++ is the notion of 
"logical const", where a supposedly "const" value is lazily set to a value upon 
first use. I.e. it isn't const, it's just pretend const.



 2. prevent common programming bugs?


 
 You can't modify const data, for instance,


I know technically what it does. But that wasn't my question.



 a copy constructor can't freely modify the source value...


C++ copy constructors are not required to declare the source as const:

"A non-template constructor for class X is a copy constructor if its first 
parameter is of type X&, const X&, volatile X& or const volatile X&, and either 
there are no other parameters or else all other parameters have default
arguments"
  -- CPP98.12.8

Again, I know technically what it does. Not the value of it. I used C for a 
decade before const was introduced. I tried using it, and discovered that head 
const added nothing much of any value and I stopped bothering with it.



 3. help with multithreaded coding problems?


 
 This is a different conversation about `immutable` and `shared`.
 `const` doesn't say anything about D's decisions relating to
 thread-locality by default, which obviously still applies.


'immutable' data is implicitly shareable. Const allows the same functions to 
work on both shared immutable and non-shared mutable data. C++ has no way to
say 
a function can work on both kinds of data, or even how to describe such data.



 4. improve code generation?


 Not a lot.


Actually, not at all. C++ const is useless for code generation because:

1. people cast away const (yes, they do!). I learned this the hard way and had 
to back out those optimizations.

2. other references may mutate it.

Because of (2) it is similarly useless in D, however, it allows the same 
functions to work on immutable and mutable data, and that does have value. (The 
optimizer can make use of immutable.)



 I mean, you speak as if `const` is a synonym for `mutable` in C++...
 const things are const.


Not only are they not (legal to cast it away!), they can be mutated by other, 
non-const pointers. (There's no way to specify "pointer to immutable" in C++.)
Furthermore, const tells you nothing about the rest of the data structure. C++ 
const is all fine if your data structure fits entirely in one struct. It's 
rather meaningless for more complex objects. You cannot write generic code:

     void doSomething(T)(const T x) {...}

and rely on it to not modify T if T is a non-trivial object.



 Alternatively, if const were spec-ed similar to C++ const, it would be
 very easy to implement TransitiveConst!T as a tool.


You could specify it, but you couldn't use it. (There'd be all kinds of
implicit 
conversion problems.) There's good reason why const is treated specially for 
overload resolution and implicit conversion. I.e.:

     void foo(const T const * const * const * p);
              const T       * const * const * q;
     foo(q); // oops!

----

One thing I quite agree with you on, though, if you really want to modify 
non-trivial const objects, then D's const isn't for you :-) If you don't
believe 
the rewards of carefully designing the data structures and functions that 
operate on them so they can be const is worth it, then D's const isn't for you. 
For me, I think it is worth it. And yes, it ain't easy, as old habits die hard.
Feb 24 2019
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sun, Feb 24, 2019 at 08:59:49PM -0800, Walter Bright via
Digitalmars-d-announce wrote:
[...]

 An interesting manifestation of this uselessness in C++ is the notion
 of "logical const", where a supposedly "const" value is lazily set to
 a value upon first use. I.e. it isn't const, it's just pretend const.


I disagree.  Logical const means the outside world can't tell that the
object has changed, because only a constant value is ever seen from
outside.  This is the basis of lazy initialization (which is part of the
concept of lazy evaluation), an important feature of FP style code, and
something that D does not support.

D's relaxed version of purity -- a function is pure if the outside world
can't see any impure semantics -- makes its scope much more widely
applicable than a strict interpretation of purity as in a functional
language.  Logical const is the same idea in the realm of mutability --
though I don't necessarily agree with C++'s anemic implementation of it.
What D could really benefit from was a statically-verifiable way of
lazily initializing something that is const to the outside world.

A derived problem with D's const is the inability to express a cached
const object.  You can't cache the object because it's const, which
greatly limits the scope of usability of const in large data structures.

The same limitation makes ref-counting such a huge challenge to
implement in D.  There is simply no way to associate a refcount with a
const object without jumping through hoops and/or treading into UB
territory by casting away const. There is no way to express that the
refcount is mutable but the rest of the object isn't. Well, you *can*
express this if you use circumlocutions like:

	struct RefCounted(T) {
		int refcount;
		const(T) payload;
	}

but that's worthless in generic code because const(RefCounted!T) !=
RefCounted!(const T). So you have to special-case every generic function
that needs to work with this type, and the special cases percolate
through the entire codebase, uglifying the code and forcing generic
functions that shouldn't need to know about RefCounted to have to know
about it so that they can work with it.


Because of these limitations, const is really only useful in low-level
modules of limited scope, in simple, self-contained data structures.
Higher-level, larger data structures are basically unusable with D's
const because lazy initialization and caching are not possible without
treading into UB territory by casting.  I'm not going to argue that
C++'s version of const is any better -- because non-enforceable const is
worthless, like you said -- but let's not kid ourselves that D's const
is that much better.  D's const is really only usable in very limited
situations, and there are many things for which it's unusable even
though logically it *could* have been applicable.


T

-- 
Two wrongs don't make a right; but three rights do make a left...
Feb 25 2019
parent Walter Bright <newshound2 digitalmars.com> writes:
On 2/25/2019 8:22 AM, H. S. Teoh wrote:

 I disagree.  Logical const means the outside world can't tell that the
 object has changed, because only a constant value is ever seen from
 outside.  This is the basis of lazy initialization (which is part of the
 concept of lazy evaluation), an important feature of FP style code, and
 something that D does not support.


We've been through the logical const discussion before. The problem with it is 
it is not machine checkable. Therefore it's a documentation thing, not a 
language thing.

The not-machine-checkable attributes should be in the domain of user-defined 
attributes. It's what they're for.



 A derived problem with D's const is the inability to express a cached
 const object.  You can't cache the object because it's const, which
 greatly limits the scope of usability of const in large data structures.


I'd like to draw a distinction between where one can USE const as apposed to 
where const has VALUE. I propose that weakening const so it can be used on data 
that is mutated anyway means it can be put to USE much more often, at a heavy 
price of a severely diminished VALUE. It's why I pressed Manu about the VALUE
of 
head const.



 The same limitation makes ref-counting such a huge challenge to
 implement in D.  There is simply no way to associate a refcount with a
 const object without jumping through hoops and/or treading into UB
 territory by casting away const. There is no way to express that the
 refcount is mutable but the rest of the object isn't. Well, you *can*
 express this if you use circumlocutions like:
 
 	struct RefCounted(T) {
 		int refcount;
 		const(T) payload;
 	}
 
 but that's worthless in generic code because const(RefCounted!T) !=
 RefCounted!(const T). So you have to special-case every generic function
 that needs to work with this type, and the special cases percolate
 through the entire codebase, uglifying the code and forcing generic
 functions that shouldn't need to know about RefCounted to have to know
 about it so that they can work with it.


We're well aware of that issue. The lack of copy-constructors was the first big 
barrier to getting ref counting working properly.



 Because of these limitations, const is really only useful in low-level
 modules of limited scope, in simple, self-contained data structures.
 Higher-level, larger data structures are basically unusable with D's
 const because lazy initialization and caching are not possible without
 treading into UB territory by casting.  I'm not going to argue that
 C++'s version of const is any better -- because non-enforceable const is
 worthless, like you said -- but let's not kid ourselves that D's const
 is that much better.  D's const is really only usable in very limited
 situations, and there are many things for which it's unusable even
 though logically it *could* have been applicable.


We'll see. I've been slowly getting better at refactoring code so I can use 
const, and as I've recounted before, the results are quite pleasing.
Feb 25 2019
prev sibling next sibling parent reply Atila Neves <atila.neves gmail.com> writes:
On Monday, 25 February 2019 at 00:38:02 UTC, Walter Bright wrote:

 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.


I have no idea what people are talking about when they mention on 
this forum that D's const is useless. Nearly every function 
parameter in my code is `in`. Nearly every variable declaration 
uses `const` instead of `auto`, the main exception being when a 
function is constructing a value to return. Most member functions 
I write are const or inout. I use const in D as I do in C++: 
pretty much everywhere. Nearly every single time a function 
parameter in my code isn't const is when it's an input range.

I happened to be working on dpp at the time I wrote this:

$ ag 'auto ' source | wc -l
67
$ ag 'const ' source | wc -l
204

The *only* problem I have with const in D is that const values 
can't be copied, which is silly. I'd expect DIP1018 to fix that.
Feb 25 2019
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.com> writes:
On 2/25/19 10:45 AM, Atila Neves wrote:

 The *only* problem I have with const in D is that const values can't be 
 copied, which is silly. I'd expect DIP1018 to fix that.


Affirmative. It was tricky.
Feb 25 2019
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/25/2019 7:45 AM, Atila Neves wrote:

 I have no idea what people are talking about when they mention on this forum 
 that D's const is useless. Nearly every function parameter in my code is `in`. 
 Nearly every variable declaration uses `const` instead of `auto`, the main 
 exception being when a function is constructing a value to return. Most member 
 functions I write are const or inout. I use const in D as I do in C++: pretty 
 much everywhere. Nearly every single time a function parameter in my code
isn't 
 const is when it's an input range.


I'm going to make an educated guess that you're experienced at FP programming!
Feb 25 2019
parent Atila Neves <atila.neves gmail.com> writes:
On Tuesday, 26 February 2019 at 03:56:27 UTC, Walter Bright wrote:

 On 2/25/2019 7:45 AM, Atila Neves wrote:

 I have no idea what people are talking about when they mention 
 on this forum that D's const is useless. Nearly every function 
 parameter in my code is `in`. Nearly every variable 
 declaration uses `const` instead of `auto`, the main exception 
 being when a function is constructing a value to return. Most 
 member functions I write are const or inout. I use const in D 
 as I do in C++: pretty much everywhere. Nearly every single 
 time a function parameter in my code isn't const is when it's 
 an input range.


 I'm going to make an educated guess that you're experienced at 
 FP programming!


Indeed.

Functional is my default in any language. The good thing about D 
is I can get my hands dirty when needed as opposed to jumping 
through hoops or forcing me to use recursion when it doesn't fit 
the problem (hello C++ metaprogramming).

I'd love it if functions were ` safe` and `pure` by default.
Feb 26 2019
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2019-02-25 01:38, Walter Bright wrote:


 D's const has teeth. Nothing can be modified through T.


What about the __mutable proposal [1]?

[1] https://github.com/dlang/dmd/pull/8315

-- 
/Jacob Carlborg
Feb 26 2019
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/26/2019 2:32 AM, Jacob Carlborg wrote:

 What about the __mutable proposal [1]?
 
 [1] https://github.com/dlang/dmd/pull/8315
 


It hasn't been approved yet, and please start another thread if you want to 
discuss it.
Feb 26 2019
parent reply Jacob Carlborg <doob me.com> writes:
On 2019-02-26 12:07, Walter Bright wrote:


 It hasn't been approved yet, and please start another thread if you want 
 to discuss it.


You have approved the pull request.

-- 
/Jacob Carlborg
Feb 27 2019
parent Walter Bright <newshound2 digitalmars.com> writes:
On 2/27/2019 3:27 AM, Jacob Carlborg wrote:

 [...]


Please start another thread.
Feb 27 2019
prev sibling next sibling parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Sunday, 24 February 2019 at 21:22:33 UTC, Walter Bright 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, and 
 I thought you were going to rewrite it. Was I mistaken?


Absolutely no, no. Yes!

"What needs to be done" is scattered throughout forum discussions 
filled with incorrect assumptions, most of which were resolved 
needing little change, absolutely nothing that justifies a 
rewrite over minor amendments (the text will be 95% the same, the 
sentiment will be 100% the same), neither I nor Manu plan to 
rewrite it. Note that none of that is reflected in the official 
review, most (if not all) of which is wrong (and you should 
update it!).

What is _actually_ going to happen is this will be an item on the 
agenda for the Foundation meeting at dconf: you will clarify the 
problems you have with the DIP; those problems will be discussed, 
evaluated and acted upon; and the DIP process will be amended to 
avoid the root cause of those problems.
Feb 24 2019
prev sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
On 25/02/2019 10:22 AM, Walter Bright wrote:

 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.


We have discussed this on IRC that const needs a redesign.
The problem is, without building a list of examples of where it fails we 
cannot really start the redesign process.

But once we do, I'm in.
Feb 24 2019
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
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.
Feb 24 2019
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.com> writes:
On 2/24/19 4:02 PM, Manu wrote:

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


Thanks for the observation. We do not think this creates a hole in the
language. Indeed there is risk for misuse but we thought it's better to 
pass the "true" source of the copy to the constructor instead of 
affixing additional qualifiers to it. There are important simplicity 
benefits to doing so because "const" is ambiguous in D as it could 
originate either from mutable or immutable data. Furthermore, the risk 
is encapsulated in the type's implementation and not as a 
misunderstanding between the caller and the callee.

I'll add that pointing out a DIP's weaknesses in order to claim an 
injustice in another DIP is a understandable, but not productive. The 
proposers (Razvan and myself) and Walter (the reviewer) do not know how 
to make DIP 1018 better. Walter and I do know, and we have shared, how 
to make DIP 1016 better.


Andrei
Feb 25 2019
parent reply Jacob Carlborg <doob me.com> writes:
On 2019-02-25 17:31, Andrei Alexandrescu wrote:


 The proposers (Razvan and myself) and Walter (the reviewer) do not know how 
 to make DIP 1018 better.


That shouldn't justify accepting a DIP that might contain problems. But 
of course, if you don't think there are any problems.

-- 
/Jacob Carlborg
Feb 25 2019
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.com> writes:
On 2/25/19 1:39 PM, Jacob Carlborg wrote:

 On 2019-02-25 17:31, Andrei Alexandrescu wrote:
 

 The proposers (Razvan and myself) and Walter (the reviewer) do not 
 know how to make DIP 1018 better.


 
 That shouldn't justify accepting a DIP that might contain problems.


Definitely.


 But of course, if you don't think there are any problems.


Not talking for Walter, but generally acceptance implies that.
Feb 25 2019
parent Walter Bright <newshound2 digitalmars.com> writes:
On 2/25/2019 10:44 AM, Andrei Alexandrescu wrote:

 On 2/25/19 1:39 PM, Jacob Carlborg wrote:

 On 2019-02-25 17:31, Andrei Alexandrescu wrote:


 The proposers (Razvan and myself) and Walter (the reviewer) do not know how 
 to make DIP 1018 better.


 That shouldn't justify accepting a DIP that might contain problems.


 
 Definitely.
 

 But of course, if you don't think there are any problems.


 
 Not talking for Walter, but generally acceptance implies that.


I can't guarantee there aren't problems (bugs) in the DIP, but I didn't find
any 
more (the ones I did find Razvan fixed). If you're familiar with the C++ copy 
ctor, it is very similar, lending credence to the notion that there isn't a big 
problem left.

Regardless, we need to move forward with this, not wring hands wondering what
to do.
Feb 25 2019
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2019-02-24 11:46, Mike Parker 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.


I think the process is flawed when not everyone plays by the same rules.

-- 
/Jacob Carlborg
Feb 25 2019
parent reply Mike Parker <aldacron gmail.com> writes:
On Monday, 25 February 2019 at 18:51:17 UTC, Jacob Carlborg wrote:

 On 2019-02-24 11:46, Mike Parker 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.


 I think the process is flawed when not everyone plays by the 
 same rules.


 From the process document:

“the DIP Manager or the Language Maintainers may allow for 
exceptions which waive requirements or responsibilities at their 
discretion.”

If you were to write a DIP for a feature they think important 
enough, it could be fast tracked, too.
Feb 25 2019
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.com> writes:
On 2/25/19 2:24 PM, Mike Parker wrote:

 On Monday, 25 February 2019 at 18:51:17 UTC, Jacob Carlborg wrote:

 On 2019-02-24 11:46, Mike Parker 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.


 I think the process is flawed when not everyone plays by the same rules.


 
  From the process document:
 
 “the DIP Manager or the Language Maintainers may allow for exceptions 
 which waive requirements or responsibilities at their discretion.”
 
 If you were to write a DIP for a feature they think important enough, it 
 could be fast tracked, too.


Thanks, Mike. We were a bit surprised ourselves by the scarce response 
during the community review stage. That said, Jacob and others, if there 
is a case for the final review please let us know.
Feb 25 2019
prev sibling next sibling parent reply bachmeier <no spam.net> writes:
On Monday, 25 February 2019 at 19:24:55 UTC, Mike Parker wrote:


 From the process document:

 “the DIP Manager or the Language Maintainers may allow for 
 exceptions which waive requirements or responsibilities at 
 their discretion.”

 If you were to write a DIP for a feature they think important 
 enough, it could be fast tracked, too.


I hate to be so negative, but when I see D's corporate management 
structure, the lack of community contribution is obvious. It 
doesn't exactly motivate contributions. This is no way to run an 
open source project. I understand that it works well for Facebook 
because everyone on the team is paid six figures, and they can be 
replaced in two hours, but an open source project is not Facebook.

I know the whole argument about why it is that way. That doesn't 
mean it's going to work.
Feb 25 2019
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.com> writes:
On 2/25/19 2:41 PM, bachmeier wrote:

 On Monday, 25 February 2019 at 19:24:55 UTC, Mike Parker wrote:
 

 From the process document:

 “the DIP Manager or the Language Maintainers may allow for exceptions 
 which waive requirements or responsibilities at their discretion.”

 If you were to write a DIP for a feature they think important enough, 
 it could be fast tracked, too.


 
 I hate to be so negative, but when I see D's corporate management 
 structure, the lack of community contribution is obvious. It doesn't 
 exactly motivate contributions. This is no way to run an open source 
 project. I understand that it works well for Facebook because everyone 
 on the team is paid six figures, and they can be replaced in two hours, 
 but an open source project is not Facebook.
 
 I know the whole argument about why it is that way. That doesn't mean 
 it's going to work.


What do you recommend? Should we carry a final review here?
Feb 25 2019
parent reply Manu <turkeyman gmail.com> writes:
On Mon, Feb 25, 2019 at 12:20 PM Andrei Alexandrescu via
Digitalmars-d-announce <digitalmars-d-announce puremagic.com> wrote:

 On 2/25/19 2:41 PM, bachmeier wrote:

 On Monday, 25 February 2019 at 19:24:55 UTC, Mike Parker wrote:


 From the process document:

 “the DIP Manager or the Language Maintainers may allow for exceptions
 which waive requirements or responsibilities at their discretion.”

 If you were to write a DIP for a feature they think important enough,
 it could be fast tracked, too.


 I hate to be so negative, but when I see D's corporate management
 structure, the lack of community contribution is obvious. It doesn't
 exactly motivate contributions. This is no way to run an open source
 project. I understand that it works well for Facebook because everyone
 on the team is paid six figures, and they can be replaced in two hours,
 but an open source project is not Facebook.

 I know the whole argument about why it is that way. That doesn't mean
 it's going to work.


 What do you recommend? Should we carry a final review here?


In my case, you could have produced useful and not-completely-wrong
rejection text with the rejection, and then not insulted me a few
times before eventually producing some actionable feedback.
I mean, its in your interest to foster contribution, not repel it.
Feb 25 2019
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/25/19 9:26 PM, Manu wrote:

 On Mon, Feb 25, 2019 at 12:20 PM Andrei Alexandrescu via
 Digitalmars-d-announce <digitalmars-d-announce puremagic.com> wrote:

 On 2/25/19 2:41 PM, bachmeier wrote:

 On Monday, 25 February 2019 at 19:24:55 UTC, Mike Parker wrote:


  From the process document:

 “the DIP Manager or the Language Maintainers may allow for exceptions
 which waive requirements or responsibilities at their discretion.”

 If you were to write a DIP for a feature they think important enough,
 it could be fast tracked, too.


 I hate to be so negative, but when I see D's corporate management
 structure, the lack of community contribution is obvious. It doesn't
 exactly motivate contributions. This is no way to run an open source
 project. I understand that it works well for Facebook because everyone
 on the team is paid six figures, and they can be replaced in two hours,
 but an open source project is not Facebook.

 I know the whole argument about why it is that way. That doesn't mean
 it's going to work.


 What do you recommend? Should we carry a final review here?


 
 In my case, you could have produced useful and not-completely-wrong
 rejection text with the rejection, and then not insulted me a few
 times before eventually producing some actionable feedback.
 I mean, its in your interest to foster contribution, not repel it.


I apologize again for my use of unkind words. If there's something else 
I can do to atone, please let me know.
Feb 25 2019
parent Walter Bright <newshound2 digitalmars.com> writes:
On 2/25/2019 6:55 PM, Andrei Alexandrescu wrote:

 If there's something else I can do to atone, please let me know.


Pistols at dawn?

Or better yet, why don't I buy both of you a beer at DConf?
Feb 25 2019
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2019-02-25 20:24, Mike Parker wrote:


  From the process document:
 
 “the DIP Manager or the Language Maintainers may allow for exceptions 
 which waive requirements or responsibilities at their discretion.”


Having it documented doesn't make it less flawed.

-- 
/Jacob Carlborg
Feb 25 2019
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.com> writes:
On 2/25/19 3:23 PM, Jacob Carlborg wrote:

 On 2019-02-25 20:24, Mike Parker wrote:
 

  From the process document:

 “the DIP Manager or the Language Maintainers may allow for exceptions 
 which waive requirements or responsibilities at their discretion.”


 
 Having it documented doesn't make it less flawed.


Jacob, are there amends you need to make to the DIP?
Feb 25 2019
next sibling parent reply Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Monday, 25 February 2019 at 20:23:58 UTC, Andrei Alexandrescu 
wrote:

 On 2/25/19 3:23 PM, Jacob Carlborg wrote:

 On 2019-02-25 20:24, Mike Parker wrote:
 

  From the process document:

 “the DIP Manager or the Language Maintainers may allow for 
 exceptions which waive requirements or responsibilities at 
 their discretion.”


 
 Having it documented doesn't make it less flawed.


 Jacob, are there amends you need to make to the DIP?


Honestly, I've not understood the rationale or the covered use 
case in letting the copy ctor mutate the ref source parameters...
Sincerely, without polemical intent.

- P
Feb 25 2019
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.com> writes:
On 2/25/19 3:41 PM, Paolo Invernizzi wrote:

 On Monday, 25 February 2019 at 20:23:58 UTC, Andrei Alexandrescu wrote:

 On 2/25/19 3:23 PM, Jacob Carlborg wrote:

 On 2019-02-25 20:24, Mike Parker wrote:


  From the process document:

 “the DIP Manager or the Language Maintainers may allow for 
 exceptions which waive requirements or responsibilities at their 
 discretion.”


 Having it documented doesn't make it less flawed.


 Jacob, are there amends you need to make to the DIP?


 
 Honestly, I've not understood the rationale or the covered use case in 
 letting the copy ctor mutate the ref source parameters...
 Sincerely, without polemical intent.


We'll look into clarifying that better, thanks.
Feb 25 2019
prev sibling next sibling parent Paul Backus <snarwin gmail.com> writes:
On Monday, 25 February 2019 at 20:41:58 UTC, Paolo Invernizzi 
wrote:

 Honestly, I've not understood the rationale or the covered use 
 case in letting the copy ctor mutate the ref source 
 parameters...
 Sincerely, without polemical intent.

 - P


Because D's const is transitive, you can't copy-construct a 
mutable object from a const source:

struct S
{
     int[] stuff;
     this(const ref S source) {
         stuff = source.stuff; // Error: can't assign const(int[]) 
to int[]
     }
}
Feb 25 2019
prev sibling next sibling parent reply Olivier FAURE <couteaubleu gmail.com> writes:
On Monday, 25 February 2019 at 20:41:58 UTC, Paolo Invernizzi 
wrote:

 Honestly, I've not understood the rationale or the covered use 
 case in letting the copy ctor mutate the ref source 
 parameters...
 Sincerely, without polemical intent.

 - P


For the same reason C++'s std::shared_pointer uses a non-const 
copy constructor.
Feb 25 2019
parent reply Olivier FAURE <couteaubleu gmail.com> writes:
On Monday, 25 February 2019 at 22:45:38 UTC, Olivier FAURE wrote:

 For the same reason C++'s std::shared_pointer uses a non-const 
 copy constructor.


Wait, no, I just checked, std::shared_pointer's copy constructor 
is const, even though it changes shared data. Ugh, that's just 
wrong.

(I kind of agree with Walter's point; I totally assumed the 
constructor would be non-const, since it mutates data it receives)
Feb 25 2019
parent Walter Bright <newshound2 digitalmars.com> writes:
On 2/25/2019 3:05 PM, Olivier FAURE wrote:

 On Monday, 25 February 2019 at 22:45:38 UTC, Olivier FAURE wrote:

 For the same reason C++'s std::shared_pointer uses a non-const copy
constructor.


 
 Wait, no, I just checked, std::shared_pointer's copy constructor is const,
even 
 though it changes shared data. Ugh, that's just wrong.
 
 (I kind of agree with Walter's point; I totally assumed the constructor would
be 
 non-const, since it mutates data it receives)


There's also no requirement that any arguments to constructors should be const. 
Why should copy-constructors be different?
Feb 25 2019
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 02/25/2019 03:41 PM, Paolo Invernizzi wrote:

 On Monday, 25 February 2019 at 20:23:58 UTC, Andrei Alexandrescu wrote:

 On 2/25/19 3:23 PM, Jacob Carlborg wrote:

 On 2019-02-25 20:24, Mike Parker wrote:


  From the process document:

 “the DIP Manager or the Language Maintainers may allow for
 exceptions which waive requirements or responsibilities at their
 discretion.”


 Having it documented doesn't make it less flawed.


 Jacob, are there amends you need to make to the DIP?


 Honestly, I've not understood the rationale or the covered use case in
 letting the copy ctor mutate the ref source parameters...
 Sincerely, without polemical intent.


I made an editorial pass:

https://github.com/dlang/DIPs/pull/145

The most material change was additional explanation of using mutable ref 
instead of e.g. const. Here's the relevant excerpt, please let me know 
if it clarifies the motivation.

=============================================
1. 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:

```d
struct A
{
     int[] a;
     this(ref A another)
     {
         another.a[2] = 3;
     }
}

void main()
{
     A a, b;
     a = b;    // b.a[2] is modified
}
```

This is surprising and potentially error-prone behavior because changing 
the source of a copy is not customary and may surprise the user of a 
type. (For that reason, C++ coding standards adopt the convention of 
taking the source by means of reference to `const`; copy constructors 
that use non-`const` right-hand side are allowed but discouraged.) In D, 
`const` and `immutable` are more restrictive than in C++, so forcing 
`const` on the copy constructor's right-hand side would make simple 
copying task unduly difficult. Consider:

```d
class Window
{
     ...
}
struct Widget
{
     private Window display;
     ...
     this(ref const Widget rhs)
     {
         display = rhs.display; // Error! Cannot initialize a Window 
from a const(Window)
     }
}
```

Such sharing of resources across objects is a common occurrence, which 
would be impeded by forcing `const` on the right-hand side of a copy. 
(An inferior workaround would be to selectively cast `const` away inside 
the copy constructor, which is obviously undesirable.) For that reason 
this DIP proposes allowing mutable copy sources.
=============================================
Feb 27 2019
parent Olivier FAURE <couteaubleu gmail.com> writes:
On Thursday, 28 February 2019 at 01:42:13 UTC, Andrei 
Alexandrescu wrote:

 Such sharing of resources across objects is a common 
 occurrence, which would be impeded by forcing `const` on the 
 right-hand side of a copy. (An inferior workaround would be to 
 selectively cast `const` away inside the copy constructor, 
 which is obviously undesirable.) For that reason this DIP 
 proposes allowing mutable copy sources.


There's an argument to be made that a copy constructor isn't the 
best way to share resources between two variables in a way that 
might affect code using the variable being copied.
Mar 03 2019
prev sibling next sibling parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Monday, 25 February 2019 at 20:23:58 UTC, Andrei Alexandrescu 
wrote:

 On 2/25/19 3:23 PM, Jacob Carlborg wrote:

 On 2019-02-25 20:24, Mike Parker wrote:
 

  From the process document:

 “the DIP Manager or the Language Maintainers may allow for 
 exceptions which waive requirements or responsibilities at 
 their discretion.”


 
 Having it documented doesn't make it less flawed.


 Jacob, are there amends you need to make to the DIP?


This whole reply chain sounds more like the problems lie with the 
DIP process not this DIP, but  I'll let Jacob answer that.
Feb 25 2019
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2019-02-25 21:23, Andrei Alexandrescu wrote:


 Jacob, are there amends you need to make to the DIP?


No, I'm talking about the process in general.

-- 
/Jacob Carlborg
Feb 26 2019
prev sibling parent RazvanN <razvan.nitu1305 gmail.com> writes:
On Sunday, 24 February 2019 at 10:46:37 UTC, Mike Parker 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


Are there any other concerns regarding the copy constructor DIP? 
Although the debate about the value of const's transitivity is an 
interesting one, it is orthogonal to this proposal.

Regarding the mutability of the copy constructor source: it is 
not mandatory that the source is mutable; you can define it as 
const, it's just that it is not going to work with mutable 
objects that contain indirections. There is no workaround for 
this, and per the current language rules this is not a problem.

As for the *by ref* rvalue DIP, I suggest that the discussion 
should be moved in an other forum thread, as the discussion is 
hijacked from getting feedback for DIP 1018

Cheers,
RazvanN
Feb 26 2019