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
