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

Arine arine123445128843 at gmail.com
Thu Feb 13 19:04:26 UTC 2020


On Tuesday, 11 February 2020 at 19:02:38 UTC, Manu wrote:
> On Tue, Feb 11, 2020 at 5:30 AM Arine via Digitalmars-d 
> <digitalmars-d at puremagic.com> wrote:
>>
>> On Tuesday, 11 February 2020 at 09:46:35 UTC, Paolo Invernizzi 
>> wrote:
>> > Let's put It simple, and let's boil this down to essential: 
>> > there's MORE probability of FUTURE breakage with named 
>> > parameters, and that's a fact.
>>
>> Only if you use the feature. That's part of the reason why I 
>> don't think you should be able to set a default of the middle 
>> argument. This just forces someone to use the feature if they 
>> want a default parameter. Neither C# nor Python allow you to 
>> set a default parameter in the middle without the rest that 
>> follow also having default values.
>>
>> Other than that, if you don't want your code to break 
>> potentially from argument changes, then don't use named 
>> parameters.
>
> As a library author, you can't control whether a client uses 
> named
> arguments or not. You must assume that they might use them 
> anywhere
> and everywhere.
> This is huge for phobos and druntime, which should have a major 
> pass
> over all function argument names to achieve dignity before we 
> set them
> in stone.

I meant that in terms of the user. A library author can choose 
what they want to do, they can break code just by changing the 
internal implementation that isn't exposed. Without changing the 
API. Ultimately you are at the mercy of the library author for 
basically everything anyways. If a library author doesn't take 
into consideration parameter names, the user can avoid breaking 
changes by simply not using them. Whether the author is right not 
to care about that can be debated, and whether it is their 
reponsibility.

Anyways I agree, druntime and phobos names should be fixed, even 
if this DIP doesn't pass.

Someone way back in the thread said something that I feel was 
overlooked. If this is only for readability, then creating a tool 
like in CLion seems like the better option. It'll have the same 
functionality (including the problem with template wrappers), 
won't burden library authors and you can opt in to use it.

https://www.jetbrains.com/help/rider/Inline_Parameter_Name_Hints.html

If you can get the desired effect without introducing a new 
feature, it should definitely be investigated.

I also don't like that you can rearrange the parameters any which 
way you want. C# doesn't allow this and it seems like it'll just 
cause more problems trying to figure out which overload was 
called. The way it is currently written can make it more 
difficult to read code.

I do want named parameters so that I don't have to write out all 
the default parameters just to get to use a different value for 
the last one. I can't think of a better solution than what he 
has, the way it is designed and used is simple. Named parameters 
would benefit it.

https://github.com/ocornut/imgui/blob/v1.75/imgui.h#L451







More information about the Digitalmars-d mailing list