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.

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

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

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

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

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.

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.

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

On 2/27/2019 3:27 AM, Jacob Carlborg wrote:
> [...]

Please start another thread.

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.