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?

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

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?

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

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.

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[]
    }
}

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.

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)

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

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