On 2/12/20 4:53 PM, Sasha wrote:
> On Wednesday, 12 February 2020 at 20:11:14 UTC, Steven Schveighoffer wrote:
>> My second most used language is Swift, which requires named parameters. There are some cool things you can do with function and parameter names when they are significant. I think it's going to be a net benefit. We just have to resolve the introspection issue.
> 
> Since I never used named arguments, I mean I never opted to and since you have, can you share about the problems, because it must have some problems, changing the names will cause problem, but how this happen in production?

Swift is notorious for making breaking changes, including function and parameter names (which are technically part of the function name), but provides generally a rich tool in xcode to upgrade your code to deal with the differences.

Of course, it's not always perfect. I was pissed when they removed for loops without providing a replacement.

But renaming of function names AND parameters is handled quite easily.

It is definitely a difference for a language that has had named parameters from the beginning vs. one that suddenly allows that. The mentality is different and the care for parameter names is different.

If this DIP is accepted, I expect some growing pains, but it should be pretty much fine pretty quickly IMO.

> Like I said above I'm curious about this feature, and why C/C++ which have a bigger user base never bothered about adding this feature.

There's lots of useful things C/C++ could add that they haven't. The bar to cross for C++ new features is going to be a difficult threshold for any feature, including named parameters, regardless of the utility or benefits. They just don't like to change much. I don't know that I would ascribe some inherent problem with named parameters as the cause of it not being in C++, or really any language. Changing a language always has to be worth it to the maintainers, and opinions on this feature differ widely even here.

-Steve

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@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

On 2/12/2020 6:00 PM, Adam D. Ruppe wrote:
> And just those two messages next to each other, spell check or no, would probably clue the user in. I doubt this will even need additional code, but nevertheless, given the importance of good error messages to user productivity, I think all DIPs ought to have a section on diagnostics and any implementation should ensure it is addressed one way or another.

It's a good idea, but I've found it to be pragmatic to not worry much about error message quality during the initial implementation, just focus on getting the semantics right. (Doing great error messages often is a significant increase in complexity.) Having some experience with the kinds of mistakes people tend to make (and it isn't random) helps a lot to guide error message development.

Hence is it something for the future, and is premature to add in the DIP for the feature. Doing it later also would not require a DIP.

Good error messages are always a work in progress.

On Friday, 7 February 2020 at 03:33:26 UTC, Jonathan M Davis wrote:
> but for the most part, they're useful because a function has way too many parameters, in which case, the function should have been designed differently.

Named parameters are not just for when there are too many parameters.

Easy example:

    dup2(a, b);

vs

    dup2(src: a, dst: b);

On 13.02.20 02:40, Walter Bright wrote:
> On 2/11/2020 12:49 AM, Timon Gehr wrote:
>> If you change the name of a field, code that accesses the field in the standard way also breaks. It would be rather weird if people complained specifically about broken initializers.
> 
> If the code followed good encapsulation techniques, it wouldn't any more than changing the name of a parameter would necessitate changing the body of the function.

Which is exactly what defeats the argument that spawned this sub-thread.

On Wednesday, February 19, 2020 8:31:00 AM MST Yuxuan Shui via Digitalmars-d wrote:
> On Friday, 7 February 2020 at 03:33:26 UTC, Jonathan M Davis
>
> wrote:
> > but for the most part, they're useful because a function has way too many parameters, in which case, the function should have been designed differently.
>
> Named parameters are not just for when there are too many parameters.
>
> Easy example:
>
>      dup2(a, b);
>
> vs
>
>      dup2(src: a, dst: b);

Named arguments are completely unnecessary in such a situation. The list of arguments is short enough that it's trivial to know which is which and what they're for. Having the parameter names listed at the call site is just unnecessary cruft, and having named arguments in the language opens up the whole issue of whether the names src and dst were the best names for dup2. Just like there's often too much arguing over what a function should be named, you then have arguing over what the function's parameters should be named and whether they're consistent with other functions, which isn't an issue right now. Right now, if the programmer maintaining dup2 wants to change the parameter names as part of working on the function's implementation, doing so is not a problem, whereas with named arguments, it would break code. Personally, I don't think that named arguments provide much value, and I _really_ don't want parameters to become part of the API. We have enough bikeshedding over names as it is and don't need to introduce yet more ways that changing libraries can break existing code. Unfortunately, given Walter's current position on this, I'm likely going to have to deal with named arguments and the problems that they bring, but I really don't have much good to say about them, and I do not look forward to having to deal with them in the least.

- Jonathan M Davis

On Wednesday, 19 February 2020 at 19:13:01 UTC, Jonathan M Davis wrote:
>>      dup2(src: a, dst: b);
>
> Named arguments are completely unnecessary in such a situation. The list of arguments is short enough that it's trivial to know which is which and what they're for.

Eh, the thing with these is it is really easy to do it backwards.

I come from intel assembly so I always think it is `mov dst, src`. Unless it is `cp src dst` which is the one exception baked into my brain.

So listing it here can legitimately be useful as a reminder when you aren't sure which style this particular function used.

On Wednesday, 19 February 2020 at 19:13:01 UTC, Jonathan M Davis wrote:
> On Wednesday, February 19, 2020 8:31:00 AM MST Yuxuan Shui via Digitalmars-d wrote:
>> On Friday, 7 February 2020 at 03:33:26 UTC, Jonathan M Davis
>>
>> wrote:
>> > but for the most part, they're useful because a function has way too many parameters, in which case, the function should have been designed differently.
>>
>> Named parameters are not just for when there are too many parameters.
>>
>> Easy example:
>>
>>      dup2(a, b);
>>
>> vs
>>
>>      dup2(src: a, dst: b);
>
> Named arguments are completely unnecessary in such a situation. The list of arguments is short enough that it's trivial to know which is which and what they're for. Having the parameter names listed at the call site is just unnecessary cruft, and having named arguments in the language opens up the whole issue of whether the names src and dst were the best names for dup2. Just like there's often too much arguing over what a function should be named, you then have arguing over what the function's parameters should be named and whether they're consistent with other functions, which isn't an issue right now. Right now, if the programmer maintaining dup2 wants to change the parameter names as part of working on the function's implementation, doing so is not a problem, whereas with named arguments, it would break code. Personally, I don't think that named arguments provide much value, and I _really_ don't want parameters to become part of the API. We have enough bikeshedding over names as it is and don't need to introduce yet more ways that changing libraries can break existing code. Unfortunately, given Walter's current position on this, I'm likely going to have to deal with named arguments and the problems that they bring, but I really don't have much good to say about them, and I do not look forward to having to deal with them in the least.
>
> - Jonathan M Davis

I agree. I know there are complaints about being required to use a particular tool to use a language, but this particular argument for named parameters uses a language change - one with big side effects - to do something that should be done by an IDE. The nice thing about proper editor support is that it continues to work exactly as expected even if you do change the parameter names in the library.

On Wednesday, 19 February 2020 at 19:34:53 UTC, bachmeier wrote:
> On Wednesday, 19 February 2020 at 19:13:01 UTC, Jonathan M Davis wrote:
>> [...]
>
> I agree. I know there are complaints about being required to use a particular tool to use a language, but this particular argument for named parameters uses a language change - one with big side effects - to do something that should be done by an IDE. The nice thing about proper editor support is that it continues to work exactly as expected even if you do change the parameter names in the library.

What editor are you specifically talking about here and how should it be done? Generating comments like this?

go(\*a*\ 1);

Alex

On Wednesday, 19 February 2020 at 19:13:01 UTC, Jonathan M Davis wrote:
> On Wednesday, February 19, 2020 8:31:00 AM MST Yuxuan Shui via
>
> Named arguments are completely unnecessary in such a situation. The list of arguments is short enough that it's trivial to know which is which and what they're for. Having the parameter names listed at the call site is just unnecessary cruft, and having named arguments in the language opens up the whole issue of whether the names src and dst were the best names for dup2.

I just can say that my professional experience leads me to believe the complete opposite. Named parameters and parameter names at the call site are useful, aid in understanding the code and prevent bugs.