DIP 1020--Named Parameters--Community Review Round 2
rikki at cattermole.co.nz
Fri Sep 13 20:02:21 UTC 2019
On 14/09/2019 7:48 AM, jmh530 wrote:
> On Friday, 13 September 2019 at 18:29:56 UTC, rikki cattermole wrote:
>> On 14/09/2019 5:49 AM, M.M. wrote:
>>> I wish they could find the energy to come up with a new DIP..
>> No point on my end.
>> I may as well explain why I created DIP 1020 officially now that it is
>> The reason is signatures.
> I feel like this is an argument you should have made much
> earlier...like...in the DIP...
I felt it was inappropriate to state such possibilities in the DIP or in
the review thread(s) as it may never came to pass.
As per the spirit of the DIP process, a DIP by itself should function as
a whole and not rely on future potential DIP's for its merit. Examples
of this can be seen in DIP 1019's review threads.
I consider DIP 1020 to have done that. Served its use cases that were
numerous without needing a potential DIP to the future to describe its
potential. However I doubt many people would agree with my belief in that.
Anyway the concept of signatures that I have, while spending 2 years on
it up to now, I had concluded before DIP 1020 was created that the only
way to implement it was to break it up into much smaller design problems
and named arguments happened to fit a key part of it.
It would have been equivalent of adding a class system to D. That is not
a small design problem and could of easily damaged the language if done
Perhaps it would have been possible 10 years ago, but D is a production
language. It had a high chance of failure.
More information about the Digitalmars-d