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

[12345swordy]

On Friday, 15 February 2019 at 21:19:14 UTC, Yuxuan Shui wrote:
> On Friday, 15 February 2019 at 20:51:35 UTC, 12345swordy wrote:
>> On Friday, 15 February 2019 at 20:35:14 UTC, Yuxuan Shui wrote:
>>> On Friday, 15 February 2019 at 19:11:55 UTC, 12345swordy 
>>> wrote:
>>>> [...]
>>>
>>> I am not saying "we should never break any code". I am 
>>> deferring that decision to someone else. If someone want to 
>>> make named parameters opt-out instead of opt-in, they can do 
>>> so on top of this DIP. I am just not doing that in my 
>>> proposal.
>>
>> Why?
>
> You answered the why yourself:
>
>> a.)This is a slow process
>> b.)Would require another 180+ days if A&W reject this.
>
> So I don't want this proposal to be rejected.

There are severe usability disadvantages that outweigh 
readability advantages if this were to be opt-in. The decision to 
used named arguments should rest on the calle not the caller. 
When the calle used named arguments they are opt-in the risk of 
their code breakage in which forcing the caller to mark their 
function @named does NOT solve this.

Here is my statement: The caller is NOT AND SHOULD NOT BE 
responsible for code breakage when they renamed parameters as the 
Named Arguments are opt-in from the client side of the code.
Forcing the Caller to be responsible for Named Arguments, is a 
HUGE usability disadvantage as it requires many existing 
libraries out there to mark their functions @named if the client 
wants to use named arguments, when they have already have other 
attributes to worry about. It even worst for library creators to 
mark @named in their modules EVERY SINGLE TIME if they to grant 
the client access to named arguments. Function not having Named 
Arguments support should be RARE NOT COMMON! This poor design 
should be the basis of this being rejected.