Re: DIP 1018--The Copy Constructor--Formal Review
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.
Re: DIP 1018--The Copy Constructor--Formal Review
On Mon, Feb 25, 2019 at 9:30 PM Walter Bright via Digitalmars-d-announce 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.
Re: DIP 1018--The Copy Constructor--Formal Review
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.
Re: DIP 1018--The Copy Constructor--Formal Review
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.
Re: DIP 1018--The Copy Constructor--Formal Review
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.
Re: DIP 1018--The Copy Constructor--Formal Review
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?
Re: DIP 1018--The Copy Constructor--Formal Review
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.
Re: DIP 1018--The Copy Constructor--Formal Review
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?
Re: DIP 1018--The Copy Constructor--Formal Review
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.
Re: DIP 1018--The Copy Constructor--Formal Review
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!
Re: DIP 1018--The Copy Constructor--Formal Review
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 :-)
Re: DIP 1018--The Copy Constructor--Formal Review
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.
Re: DIP 1018--The Copy Constructor--Formal Review
On Mon, Feb 25, 2019 at 3:10 PM Olivier FAURE via Digitalmars-d-announce 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.
Re: DIP 1018--The Copy Constructor--Formal Review
On 2/25/19 9:26 PM, Manu wrote: On Mon, Feb 25, 2019 at 12:20 PM Andrei Alexandrescu via Digitalmars-d-announce 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.
Re: DIP 1018--The Copy Constructor--Formal Review
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.
Re: DIP 1018--The Copy Constructor--Formal Review
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.
Re: DIP 1018--The Copy Constructor--Formal Review
On Mon, Feb 25, 2019 at 12:20 PM Andrei Alexandrescu via Digitalmars-d-announce 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.
Re: DIP 1018--The Copy Constructor--Formal Review
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.
Re: DIP 1018--The Copy Constructor--Formal Review
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.
Re: DIP 1018--The Copy Constructor--Formal Review
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.
Re: DIP 1018--The Copy Constructor--Formal Review
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
Re: DIP 1018--The Copy Constructor--Formal Review
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)
Re: DIP 1018--The Copy Constructor--Formal Review
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).
Re: DIP 1018--The Copy Constructor--Formal Review
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.
Re: DIP 1018--The Copy Constructor--Formal Review
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[]
}
}
Re: DIP 1018--The Copy Constructor--Formal Review
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.
Re: DIP 1018--The Copy Constructor--Formal Review
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
sumtype 0.8.3
SumType is a generic sum type for modern D. It is meant as an alternative to `std.variant.Algebraic`. Features: - Pattern matching, including support for structural matching (★) - Self-referential types, using `This` - Works with pure, @safe, @nogc, and immutable (★) - Zero runtime overhead compared to hand-written C - No heap allocation - Does not rely on runtime type information (`TypeInfo`) (★) Starred features (★) are those that are missing from `Algebraic`. Code examples are available in the documentation (linked below). New since the last announced version, 0.7.0: - SumType now accepts non-copyable types as members. - A new template, `canMatch`, allows querying the matching logic directly. - A bug in the `==` operator of self-referential SumTypes has been fixed. - An exception-safety bug in SumType's assignment operator has been fixed. - The documentation and examples have been given some additional polish. Special thanks to Atila Neves and John Colvin for their contributions to this release. Links: - Documentation: https://pbackus.github.io/sumtype/sumtype.html - DUB: https://sumtype.dub.pm - Github: https://github.com/pbackus/sumtype
Re: DIP 1018--The Copy Constructor--Formal Review
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
Re: DIP 1018--The Copy Constructor--Formal Review
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?
Re: DIP 1018--The Copy Constructor--Formal Review
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?
Re: DIP 1018--The Copy Constructor--Formal Review
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.
Re: DIP 1018--The Copy Constructor--Formal Review
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.
Re: DIP 1018--The Copy Constructor--Formal Review
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.
Re: DIP 1018--The Copy Constructor--Formal Review
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
Re: DIP 1018--The Copy Constructor--Formal Review
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.
Re: DIP 1018--The Copy Constructor--Formal Review
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
Re: DIP 1018--The Copy Constructor--Formal Review
On 2/24/19 4:02 PM, Manu wrote: On Sun, Feb 24, 2019 at 2:50 AM Mike Parker via Digitalmars-d-announce 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
Re: DIP 1018--The Copy Constructor--Formal Review
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...
Re: DIP 1018--The Copy Constructor--Formal Review
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.
Re: DIP 1018--The Copy Constructor--Formal Review
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
Re: DIP 1018--The Copy Constructor--Formal Review
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.
