On Wednesday, 12 February 2020 at 19:44:52 UTC, SashaGreat wrote:
> On Wednesday, 12 February 2020 at 07:42:32 UTC, aliak wrote:
>> Named arguments is the difference between spending 1 second looking at this:
>>
>> makeWindow(x: 67, y: 98, width: 100, height: 100)
>>
>> Or taking about 1 to 5 minutes depending on how easy documentation is to find, and how bored you are to figure out what this is doing:
>>
>> makeWindow(67, 98, 100, 100)
>
> You're using an example in favor of a point, because it's hard to someone use constants for this kind of thing for a production code, at least for obvious reasons it shouldn't.
>
> Now let's compare:
>
>> makeWindow(x: 67, y: 98, width: 100, height: 100)
>
> With:
>
> makeWindow(x, y, width, height);
>

You could use variables to make it look nicer at the call-side, but the downside is there's no guarantee that those variable names have any relation to the names of the parameters. For example, this would still compile:

makeWindow(x, width, y, height);

This problem can't happen with named arguments.  Named arguments also saves you if the function arguments change names/meaning, i.e.

ORIGINAL: void makeWindow(int x, int y, int width, int height)
MODIFIED: void makeWindow(int left, int top, int right, int bottom);

The version that doesn't use named arguments will still compile and run:

makeWindow(x, y, width, height);

But named arguments would catch the problem at compile-time:

makeWindow(x: 67, y: 98, width: 100, height: 100); // error no argument named 'x', 'y', 'width', 'height'

On Wednesday, 12 February 2020 at 21:11:12 UTC, Jonathan Marler wrote:
> You could use variables to make it look nicer at the call-side, but the downside is there's no guarantee that those variable names have any relation to the names of the parameters. For example, this would still compile:
>
> makeWindow(x, width, y, height);
>
> This problem can't happen with named arguments.  Named arguments also saves you if the function arguments change names/meaning, i.e.
>
> ORIGINAL: void makeWindow(int x, int y, int width, int height)
> MODIFIED: void makeWindow(int left, int top, int right, int bottom);
>
> The version that doesn't use named arguments will still compile and run:
>
> makeWindow(x, y, width, height);
>
> But named arguments would catch the problem at compile-time:
>
> makeWindow(x: 67, y: 98, width: 100, height: 100); // error no argument named 'x', 'y', 'width', 'height'

OK, now let's see a problem with named arguments, imagine this:

makeWindow(x, y, width, height);

You can call this function like:

makeWindow(x: 67, y: 98, width: 100, height: 100); // Name Arguments
makeWindow(67, 98, 100, 100); // Constants
makeWindow(x, y, width, height); // Variables

So far so good, but later someone decides to rename some parameters to:

makeWindow(posx, posy, width, height); // Note: x => posx and y => posy

makeWindow(x: 67, y: 98, width: 100, height: 100); // Ops not working anymore!
makeWindow(67, 98, 100, 100); // Constants still works
makeWindow(x, y, width, height); // Variables Still works

What I mean is that we need to balance this better, you showed a defect without Named Arguments and I'm showing a problem with.

But one thing that called my attention is that for what I see C++ doesn't has this feature, and proposes were rejected because the problems that would be created with this feature.

Sasha.

On Wednesday, 12 February 2020 at 21:47:12 UTC, Sasha wrote:
> But one thing that called my attention is that for what I see C++ doesn't has this feature, and proposes were rejected because the problems that would be created with this feature.
>
> Sasha.

Which pretty much doesn't exist in the existing languages that have named arguments, be it C#.

At most you just add a note in release notes about the functions being renamed.

I could see it an issue in dynamic languages like Python, because such a change could pass silently and then crash your program in runtime. But in D it just wouldn't compile, so it's an easy fix.

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?

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.

Sasha.

On Wednesday, 12 February 2020 at 21:53:32 UTC, Sasha wrote:
> 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.
>
> Sasha.

The only official, publicly-available information I could find on this [1] is frustratingly vague, but I did stumble across a reddit thread [2] that discusses some of the potential issues.

One is that different implementations of the C and C++ standard libraries can (and do) use different parameter names for the same functions. Unless those names were standardized, any code that called such functions using named arguments would not be portable among different implementations. In D, this is not a problem, because there is only one implementation of Phobos and Druntime, so the names are de-facto standardized already.

[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4327.html#150
[2] https://www.reddit.com/r/cpp/comments/5mdes5/what_happened_to_the_named_parameter_proposal/

On Wednesday, 12 February 2020 at 21:47:12 UTC, Sasha wrote:
> On Wednesday, 12 February 2020 at 21:11:12 UTC, Jonathan Marler wrote:
>> You could use variables to make it look nicer at the call-side, but the downside is there's no guarantee that those variable names have any relation to the names of the parameters. For example, this would still compile:
>>
>> makeWindow(x, width, y, height);
>>
>> This problem can't happen with named arguments.  Named arguments also saves you if the function arguments change names/meaning, i.e.
>>
>> ORIGINAL: void makeWindow(int x, int y, int width, int height)
>> MODIFIED: void makeWindow(int left, int top, int right, int bottom);
>>
>> The version that doesn't use named arguments will still compile and run:
>>
>> makeWindow(x, y, width, height);
>>
>> But named arguments would catch the problem at compile-time:
>>
>> makeWindow(x: 67, y: 98, width: 100, height: 100); // error no argument named 'x', 'y', 'width', 'height'
>
> OK, now let's see a problem with named arguments, imagine this:
>
> makeWindow(x, y, width, height);
>
> You can call this function like:
>
> makeWindow(x: 67, y: 98, width: 100, height: 100); // Name Arguments
> makeWindow(67, 98, 100, 100); // Constants
> makeWindow(x, y, width, height); // Variables
>
> So far so good, but later someone decides to rename some parameters to:
>
> makeWindow(posx, posy, width, height); // Note: x => posx and y => posy
>
> makeWindow(x: 67, y: 98, width: 100, height: 100); // Ops not working anymore!
> makeWindow(67, 98, 100, 100); // Constants still works
> makeWindow(x, y, width, height); // Variables Still works
>
> What I mean is that we need to balance this better, you showed a defect without Named Arguments and I'm showing a problem with.
>
> But one thing that called my attention is that for what I see C++ doesn't has this feature, and proposes were rejected because the problems that would be created with this feature.
>
> Sasha.

My point was the the error is caught at compile-time rather than runtime, which I think is a pro in the named arguments column.

That being said, the issue you brought up with named arguments is a valid issue and would be my biggest argument against them.  They dramatically increase the surface area of the API which will lead to more breakage between libraries.  For this reason and the fact that I think named arguments are only useful in a minority of cases (maybe 25%?) I think it would be  better to make named arguments "opt-in" so that each library can choose when to make their parameter names apart of their API.

On 2/11/2020 11:42 PM, aliak wrote:
> Or taking about 1 to 5 minutes depending on how easy documentation is to find, and how bored you are to figure out what this is doing:

As an aside, this is why I encourage URLs to be put right in the source code with links to relevant information like bugzilla issues, spec pages, API documentation, etc.

On 2/8/2020 6:31 PM, Adam D. Ruppe wrote:
> I would kinda love user-defined warnings. pragma(msg) comes close sometimes but there is no way to conditionally trigger it.

    static if (condition) pragma(msg, "Look, Ma!");

Or static assert().

> A reasonable thing for the compiler to do btw would be to call out when function names change. Suppose you have:
> 
> foo(bar: 1, baz: 4)
> 
> and later you change the signature to
> 
> foo(int bar, int coolness)
> 
> the compiler could reasonably issue an error:
> 
> error: foo has no parameter named `baz`. Did you mean `coolness`?
> 
> based on process of elimination to suggest the names not yet specified to ease transition.

Note that the compiler already uses a spell checker to look for close symbol matches.

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.

On Thursday, 13 February 2020 at 01:37:58 UTC, Walter Bright wrote:
>     static if (condition) pragma(msg, "Look, Ma!");

In this context, the condition there would be someone using the parameter names. That's impossible to find in static if.

> Note that the compiler already uses a spell checker to look for close symbol matches.

A spell checker wouldn't necessarily catch a name change like this since the distance between old and new name may be significant. (e.g. ms to milliseconds has an edit distance of ... what, 11?)

The current spell checker doesn't do it:

int milliseconds() { return 0; }

void main() {
        int a = ms();
}

// wer.d(4): Error: undefined identifier ms
// note no suggestion given


But since the number of parameters is so limited, process of elimination means even with a very large edit distance, it is still probable that you meant one of the few missing parameters. Like dmd will right now suggest:

wer.d(4): Error: function wer.milliseconds(int ms) is not callable using argument types ()
wer.d(4):        missing argument for parameter #1: int ms


So a natural extension of this could be

    given named argument `milliseconds` does not match any parameter
    missing argument for parameter #1: int ms


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.