DIP 1020--Named Parameters--Community Review Round 2

[rikki cattermole]

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 
>> dead.
>>
>> The reason is signatures.
>> [snip]
> 
> 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 
wrong.

Perhaps it would have been possible 10 years ago, but D is a production 
language. It had a high chance of failure.