DIP 1019--Named Arguments Lite--Community Review Round 1

[12345swordy]

On Friday, 15 February 2019 at 20:11:47 UTC, Paul Backus wrote:
> On Friday, 15 February 2019 at 19:11:55 UTC, 12345swordy wrote:
>> On Friday, 15 February 2019 at 18:26:34 UTC, Yuxuan Shui wrote:
>>> Yes, one of my "design goal" is to maximize my chance :)
>>
>> Increasing the chance of this DIP being accepted by avoiding 
>> code deprecation shouldn't be any DIP design goal. We 
>> shouldn't reject good design just because it may break people 
>> code.
>>
>> [...]
>>
>> D should not make the fatal mistake of "persevering backwards 
>> capability at all cost" scenario, that what c++ is for.
>
> It's actually worse than that--the purpose of @named is not to 
> avoid breaking *existing* code. Existing code that doesn't use 
> named arguments will continue to work regardless. The purpose 
> of @named is to ensure that (a) changes to existing code which 
> have yet to be made (b) do not break future code that has yet 
> to be written.
Which it is a non-issue in other languages such as C# as the 
simple find and replace tool in your favorite editor can simply 
fix the code breakage due to parameter name change.
This should really be opt-out rather then opt-in, as parameter 
name changes are rare and easy to fix. I don't think library 
authors should be nagged by user to put the @named attribute to 
their functions just so they can use Named Arguments! If the 
calle is so worried about their code break, because of the name 
change of the parameter, then they shouldn't be using name 
arguments at all!

I don't want Named Arguments to be dead on arrival, as your 
favorite library hasn't updated their functions to use the named 
arguments feature.

-Alex