DIP 1030--Named Arguments--Community Review Round 1 Discussion

[aliak]

On Monday, 10 February 2020 at 23:48:05 UTC, Manu wrote:
> Ummm... you're saying bad API names has a "very low 
> probability"? Finish this sentence: "There are 2 hard problems 
> in computer science..."

Off by 1 errors?

:)

>
> I mean, I'm constantly tweaking API's for intuitive appeal. 
> Programmers do this _all the time_.

Agreed. If it's any conciliation (i assume probably not but 
anyway), in swift you take a little bit more time to name things, 
but in my experience maintainability goes up 10x. Also, it has 
not really been an issue when doing scala or kotlin.

>
>> We literally have two named arguments DIP that are postponed 
>> for this DIP. The discussion has been made so many times 
>> already in which your concerns and objections has brought up 
>> time and time again. Which frankly I don't have time nor the 
>> energy to argue in favor it again when you can look into those 
>> discussions threads already.
>
> I've never posted a single comment in a named argument thread. 
> It's
> just not a thing I care about.
> I commented today because I feel like this DIP has a high 
> probability
> of acceptance (because Walter wrote it), and I wanted to 
> understand
> what was about to happen.
>
> I'm still mostly ambivalent about this, but I'm concerned 
> you're still
> carefully avoiding my key concern; I showed an entire class of 
> code
> that will be broken, you need to have a response to that.
> Basically everything I've ever written in a professional 
> capacity will
> cease working if clients can call with named arguments.
>
>> There is no apocalypse scenario in C# community, when it comes 
>> to named arguments.
>
> They didn't have a decade of existing and important code that 
> will break.

C# didn't get named params till 2009 it seems (version 4.0).