On Sunday, 17 February 2019 at 17:09:57 UTC, Yuxuan Shui wrote:
> And they have the problem that the name of the parameter becomes part of the API. This is something this DIP tries to solve.
A better solution would be allowing nameless parameters functions and refer the parameters by index.

-Alex

On Sunday, 17 February 2019 at 17:48:33 UTC, 12345swordy wrote:
> On Sunday, 17 February 2019 at 17:09:57 UTC, Yuxuan Shui wrote:
>> And they have the problem that the name of the parameter becomes part of the API. This is something this DIP tries to solve.
> A better solution would be allowing nameless parameters functions and refer the parameters by index.
>
> -Alex

This possibility exists already via variadic templates and via

´´´
void main()
{
    fun(4, "kuku");
}

void fun(int, string)
{
    import std.stdio;
    writeln(_param_0);
    writeln(_param_1);
}
´´´

On Sunday, 17 February 2019 at 17:09:57 UTC, Yuxuan Shui wrote:
> On Sunday, 17 February 2019 at 13:12:11 UTC, Rubn wrote:
>>
>> I'd say enabling named parameters for everything would be better than any benefits you get with using an attribute.
>>
>>     @named void foo(int a, int b);
>>     @named void foo(int c, int d);
>>
>> I don't find the above situation all that useful. There are multiple ways to deal with this. Using another type for the parameters:
>>
>>     void foo( Size ab );
>>     void foo( Point cd );
>>
>> Or simply give the functions a different name to distinguish between them.
>>
>> Allowing two functions to exist with the same type signature just adds unnecessary complexity.
>
> This is allowed, _right now_. This is not an addition made by this DIP. Example: https://d.godbolt.org/z/hbwsaU

Yes that's very different from what you want to implement it. See below.

>> Looking at a few languages that support named parameters they don't support this kind of named parameters. This includes C# and Python.
>>
>>     def abc(a, b):
>>         print( "ab", a, b)
>>
>>     def abc(c, d):
>>         print( "cd", c, d)
>>
>>     abc(c=10, d=20)
>>     abc(a=12, b=23) # error the second def of abc() replaces the first
>
> And they have the problem that the name of the parameter becomes part of the API. This is something this DIP tries to solve.
>
>>
>> If you want this functionality you are probably going to have to make a more concrete case for it than what is currently in the DIP. If there are any languages that implement it the way you want to implement it it would probably be a good idea to include them as examples.
>
> I am pretty sure this DIP listed some major languages with this feature, and it also includes concrete examples.

Yes and Python doesn't behave the way you are suggesting. Listing the languages that implement the feature but not how they implement it makes the argument weaker. You list Python but I would not say Python implements this feature the same way as you are suggesting it to be implemented. I'd use Python as an example against this DIP (as I have).

Eg the DIP suggests this be valid code so long as it can be distinguished by at least one parameter.

    @named:
    int add(int a, int b) { ... }
    int add(int c, int d) { ... }

If you try and do the following currently:

    int add(int a, int b) { ... }
    int add(int c, int d) { ... } // error

You get a compiler error. Defining two functions with the same type signatures shouldn't be possible, with or without named parameters. It just adds un-needed complexity.

On Sunday, 17 February 2019 at 17:48:33 UTC, 12345swordy wrote:
> On Sunday, 17 February 2019 at 17:09:57 UTC, Yuxuan Shui wrote:
>> And they have the problem that the name of the parameter becomes part of the API. This is something this DIP tries to solve.
> A better solution would be allowing nameless parameters functions and refer the parameters by index.
>
> -Alex

That'd be worse, it'd make code less readable, the opposite of what named parameters are for.

I might be misunderstanding something, but with this code:

int add(int x, int y);
@named:
int add(int c, int d);

What happens if I do add(5, 6)?  Won't that be ambiguous?

On Sunday, 17 February 2019 at 18:23:13 UTC, Elronnd wrote:
> I might be misunderstanding something, but with this code:
>
> int add(int x, int y);
> @named:
> int add(int c, int d);
>
> What happens if I do add(5, 6)?  Won't that be ambiguous?

All declarations with the same signature must refer to the same function. Or, in other words, only one of them can have a function body, and that body will be used for all calls that match any of the equivalent declarations.

Redundant declarations like this are actually already allowed in D; there just isn't any particular reason you'd want to use them. Example: https://run.dlang.io/is/MSmiF5

On Sunday, 17 February 2019 at 18:00:46 UTC, Rubn wrote:
> On Sunday, 17 February 2019 at 17:48:33 UTC, 12345swordy wrote:
>> On Sunday, 17 February 2019 at 17:09:57 UTC, Yuxuan Shui wrote:
>>> And they have the problem that the name of the parameter becomes part of the API. This is something this DIP tries to solve.
>> A better solution would be allowing nameless parameters functions and refer the parameters by index.
>>
>> -Alex
>
> That'd be worse, it'd make code less readable, the opposite of what named parameters are for.

That is only if you are so worried about "parameter name becomes part of the API", which such concerns should be the exception, not the norm. I have never ever encounter anyone in the c# community that worry about named parameter becomes part of the API, when named parameters are introduced.

Client can simply use find and replace if the library they using change their parameter name. It is not a deal breaker as the DIP making out to be.

Regardless, my objections still stand regarding @named attribute and I can not tell other people with a straight face that in order to use named parameters they have to use @named attribute without expecting them to look at me like "Are you insane?"

I do not want D design to be worst, because of the "avoiding breaking code at all cost" mentality. That is what C++ is for.

On Sunday, 17 February 2019 at 17:14:57 UTC, Yuxuan Shui wrote:
> On Sunday, 17 February 2019 at 13:44:09 UTC, Cym13 wrote:
>> [...]
>
> Sure, but it has the exactly same property as @named: it's opt-in.
>
> Yes, maybe you can do it with a one-liner (I don't know how. There doesn't seem to be a way to retrieve parameter names from a function), but that can't be easier than adding "@named".
>
>> [...]
>
> So it probably could be reused?

It already exists std.traits: ParameterIdentifierTuple

Kind regards
Andre

On Sunday, 17 February 2019 at 18:57:26 UTC, 12345swordy wrote:
> Regardless, my objections still stand regarding @named attribute and I can not tell other people with a straight face that in order to use named parameters they have to use @named attribute without expecting them to look at me like "Are you insane?"
>
> I do not want D design to be worst, because of the "avoiding breaking code at all cost" mentality. That is what C++ is for.

While I still think @named attribute feels weird, I know at least one language that requires opt-in for named arguments: Dart. An example is here: https://stackoverflow.com/a/13264231 . In Dart, you can mark arguments as named:

getHttpUrl(String server, String path, {int port: 80})

and then call it:

getHttpUrl('example.com', '/index.html', port: 8080);

and you MUST use the name if it's a named argument.

Also, mixing optional arguments and named arguments is just not allowed, so it solves the issue of how to deal with such ambiguous cases:

thisFunctionWontWork(String foo, [String positonal], {String named})

On Sunday, 17 February 2019 at 19:52:14 UTC, JN wrote:
> On Sunday, 17 February 2019 at 18:57:26 UTC, 12345swordy wrote:
>> Regardless, my objections still stand regarding @named attribute and I can not tell other people with a straight face that in order to use named parameters they have to use @named attribute without expecting them to look at me like "Are you insane?"
>>
>> I do not want D design to be worst, because of the "avoiding breaking code at all cost" mentality. That is what C++ is for.
>
> While I still think @named attribute feels weird, I know at least one language that requires opt-in for named arguments: Dart. An example is here: https://stackoverflow.com/a/13264231 . In Dart, you can mark arguments as named:
>
> getHttpUrl(String server, String path, {int port: 80})
>
> and then call it:
>
> getHttpUrl('example.com', '/index.html', port: 8080);
>
> and you MUST use the name if it's a named argument.
>
> Also, mixing optional arguments and named arguments is just not allowed, so it solves the issue of how to deal with such ambiguous cases:
>
> thisFunctionWontWork(String foo, [String positonal], {String named})

Even though that is interesting, what is being currently presented is optional and not a requirement when the user call functions that are marked @Named. That quite different from Dart.

-Alex