Copy Constructor DIP

[rikki cattermole]

On 14/07/2018 11:49 PM, Johan Engelen wrote:
> On Saturday, 14 July 2018 at 10:53:17 UTC, Andrei Alexandrescu wrote:
>>
>> I now deeply regret ever telling Razvan to mention future possible 
>> directions. This DIP must do implicit copy constructors and do it 
>> well, nothing less and nothing more.
> 
> Strongly agree with this.
> In my review on Github I had a few sentences about this, but I removed 
> them because I thought it may be perceived wrong. I find it almost 
> completely irrelevant to add a "future directions" discussion to a DIP. 
> If a DIP is incomplete, then finish it. Other than that, a DIP should 
> stand completely on its own, regardless of speculation on future 
> directions.
> 
> -Johan

Really any mention of the "future" in a DIP section wise, should be 
fairly concrete.

I.e. this is already a good design, BUT it may come to pass that this 
use case is indeed important to support (an acknowledgement to its 
existence) so here is an idea on how to support it.

It doesn't need to be entirely thought out, it just needs to be pretty 
well thought out and with clear added complexity as to why it isn't part 
of the original DIP.

The example I'll use is my named arguments DIP[0], where I show a 
feature that could be added to allow renaming of args. However, because 
I'm unconvinced that such a complex feature is even needed, I don't 
support it.

[0] 
https://github.com/rikkimax/DIPs/blob/named_args/DIPs/DIP1xxx-RC.md#future-proposals