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

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.

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

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

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

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.

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

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.

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.

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.