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

[Jonathan Marler]

On Thursday, 6 June 2019 at 20:22:17 UTC, 12345swordy wrote:
> On Thursday, 6 June 2019 at 20:10:06 UTC, Jonathan Marler wrote:
>> On Thursday, 6 June 2019 at 20:04:09 UTC, 12345swordy wrote:
>>> On Thursday, 6 June 2019 at 19:17:38 UTC, Jonathan Marler 
>>> wrote:
>>>> [...]
>>>
>>> This has been brought up in the discussion regarding named 
>>> arguments for DIP1020 (more specifically the @named 
>>> attribute) and so far I am not convinced that this is an 
>>> issue that needs to be address, and found it be be overblown 
>>> given that we have powerful rename tools at this day of age.
>>>
>>> Having it "opt-in" have it own downsides as the users have to 
>>> request library developers to add the capability to their 
>>> libraries. Among many other issues that were brought up and 
>>> discuss with "opt-in"ing DIP1020.
>>>
>>> Alex
>>
>> Rename tools are irrelevant as they only work when you're in a 
>> single project.
> No, they are not irrelevant, that what C# developers such as 
> myself use when the named argument name has been change.
>

You missed the point.  I'm talking about libraries (like druntime 
and phobos) now have all their function parameters exposed.  If 
they need to change them, you can't use a replace tool on every 
single D project in the world that depends on DRuntime and 
Phobos.  Thus, replace tools are irrelevant in this case.

>>  Exposing the parameters names of every function would mean 
>> the we would pretty much need to keep all the parameter names 
>> in every function in druntime/phobos, otherwise we would break 
>> compatibility.
>
> We have a deprecated attribute for a very good reason.

Yes there are solutions, but you have to weigh the cost with the 
benefit.  There are not that many functions that will benefit 
from using named parameters.  I'd guess around 15% of all 
functions would use them, and you're breaking encapsulation with 
all 100% of functions to accommodate the 15%.  It's a high cost 
compared to the benefit.

However, if you make it "opt-in", then you don't have to pay that 
high cost.

>
>> Far to high of a cost just to allow some cases to be more 
>> readable.
>
> I strongly reject this claim, due to the lack to evidence. I 
> encounter no apocalypse scenario when it comes to unable to 
> named arguments in the C# community which you can not opt it 
> out.
>

It's the same argument for having private fields in classes and 
structs. If you don't understand the benefits of encapsulation 
then I'm not sure what to say.  The more coupling and internals 
you expose, the more opportunity to break your interface.  And 
because functions are such a big part of D, you're making the 
language overall much more brittle than it was before.