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

[Jonathan Marler]

On Friday, 7 June 2019 at 15:28:00 UTC, Gregor Mückl wrote:
> On Friday, 7 June 2019 at 15:15:40 UTC, Jonathan Marler wrote:
>> On Friday, 7 June 2019 at 12:09:51 UTC, Yuxuan Shui wrote:
>>> On Thursday, 6 June 2019 at 19:17:38 UTC, Jonathan Marler 
>>> wrote:
>>>> [...]
>>>
>>> Where were you during the last community review? :)
>>>
>>> Last time literally _everyone_ is arguing against named 
>>> parameters being opt-in, and that's why I removed the 
>>> opt-in-ness (the @named attribute) from the DIP.
>>>
>>
>> I'm not actually sure if they should be opt-in. I'm pointing 
>> out the problem with them always being on. They way I 
>> suggested for them to be opt-in has 2 problems. One is that 
>> libraries will need to break compatibility with older 
>> compilers to enable them. Without opt-in, only the caller 
>> needs to do this. The second is that it users will have to 
>> wait for libraries to update before they can use the feature, 
>> and libraries may be hesitant to update to remain compatible 
>> with older compilers, at least for a while.
>>
>> I'm just pointing out a problem I see. We should all be aware 
>> of the problem. Whether or not the problem is a big deal or 
>> had a good solution is another question. I think it's a big 
>> deal, and we should solve it if we can.
>>
>
> C# has had named arguments for quite a while now without any 
> way to opt in or opt out. If you want to name a function 
> argument, you just do it. If it breaks, it breaks. I haven't 
> seen breakage from that in practice, yet. Mostly, because 
> people only use that syntax for complex functions that have 
> long parameter lists or challenging parameter lists with 4 to 5 
> boolean parameters in row or something borderline insane like 
> that. So, I'd say that it's in the ballpark of one in 1000 LoCs 
> or less that actually use that language feature.
>

Maybe I am over-estimating the problem with exposing parameter 
names.  It was also pointed out that python actually does expose 
all it's parameter names, not just kwargs.

If people only use parameter names in cases where they make 
sense, then I agree that this is a non-issue.  By making it 
opt-in, you can guarantee that you're library won't be misused so 
you will still be free to change it without people complaining 
when you break their mis-use of your library. The less people 
mis-use the feature, the less of a problem it becomes.

I'd be curious to see how named parameters has affected 
development decisions for libraries in C#.  The Microsoft .NET 
Framework Libraries are pretty exhaustive, and once an API is in 
place, it usually never changes.  They usually only *ADD* new 
APIs and rarely change existing ones. I wonder if they had any 
issues with legacy parameter names that weren't necessarily 
consistent once they enabled named parameters for everything.  
Something to look into.