On Saturday, 16 February 2019 at 16:09:59 UTC, 12345swordy wrote:
> I *WILL* oppose this dip in it's entirely unless you remove the @named attribute requirement from it.

Please calm down. We're just discussing merits, there's no need for ultimatums.

On Sunday, 17 February 2019 at 00:38:33 UTC, Olivier FAURE wrote:
> On Friday, 15 February 2019 at 20:35:14 UTC, Yuxuan Shui wrote:
>> I am not saying "we should never break any code". I am deferring that decision to someone else. If someone want to make named parameters opt-out instead of opt-in, they can do so on top of this DIP. I am just not doing that in my proposal.

I forgot to say, thank you for your work on this DIP, and for your upbeat attitude in discussing possible improvements :)

On Sunday, 17 February 2019 at 00:41:24 UTC, Olivier FAURE wrote:
> On Saturday, 16 February 2019 at 16:09:59 UTC, 12345swordy wrote:
>> I *WILL* oppose this dip in it's entirely unless you remove the @named attribute requirement from it.
>
> Please calm down. We're just discussing merits, there's no need for ultimatums.

I am calm down, as the other poster said, we shouldn't accept this dip on the assumption that someone somewhere will write a DIP that will deprecated @named. If that were the case, then this dip is bad to begin with. Expressing my strong objections to this is no way me being not calm, and I would appreciated that you didn't misinterpret my post.

-Alex

On Sunday, 17 February 2019 at 00:27:42 UTC, Yuxuan Shui wrote:
> It's not my favorite either. But I feel it is the best we can do
> at the moment.

Sorry, but I will vote against a DIP with @named. With no guarantee that the opt-in will ever become opt-out or always available, the feature IMO will not carry its weight due to the problems I mentioned.

> I don't see why forward declaration won't work for templated functions.

Will you need to expand the implicit template declaration (R fun(A)(A a){} => template fun(A) { R fun(A a) {} })? Or will the compiler need to detect that templates are part of the overload? I would suggest to consult with a DMD frontend expert to make sure the DIP is not overly difficult to implement.

> And I don't quite understand why there might be linking problems. Can
> you give an example?

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

Let's say you want to add an optional argument to add.

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

but you forget to update the other forward declaration to match.

You will not get a compiler error. You will not get a linking error if you never used the second declaration. But, a user using your library will now get a linking error if their code used the other declaration.

I realized another problem after I sent my post: This approach is not usable for interface methods, and abstract methods (which may or may not have a body).

On Sunday, 17 February 2019 at 00:41:24 UTC, Olivier FAURE wrote:
> On Saturday, 16 February 2019 at 16:09:59 UTC, 12345swordy wrote:
>> I *WILL* oppose this dip in it's entirely unless you remove the @named attribute requirement from it.
>
> Please calm down. We're just discussing merits, there's no need for ultimatums.

Telling someone that is angry or distressed to calm down is just about the worse thing you could say to them. Just saying, if were you were trying to calm someone down, you would have just been agitating them further.

On Sunday, 17 February 2019 at 00:27:42 UTC, Yuxuan Shui wrote:
>>> Opt-in: Calling a function with named arguments is opt-in on the callee side.
>>
>> @named is not the best idea. I don't want to have to check every time if the library author remembered to slap @named on the function I want to use named arguments with. Making it opt-in will probably mean that there will be people who use it and those who don't, and libraries written by users who don't will just cause frustration by those who do; and, for people who do, they might as well just slap it on everything, further contributing to attribute bloat. Also, the decision to use named arguments depends as much on the function as on the call site (e.g. how important is code readability vs. terseness in that particular piece of code). I'd be just too tempted to patch the compiler to enable it for everything.
>
> It's not my favorite either. But I feel it is the best we can do
> at the moment.

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.

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

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.

On Saturday, 16 February 2019 at 12:41:01 UTC, Andre Pany wrote:
>
> With the struct initialization DIP there will come also named arguments complicity.
>
> https://github.com/wilzbach/DIPs/blob/b1283b455b635d7dcbc2c871d2aa47cc67190059/DIPs/DIP1xxx-sw.md
>
> Yes, the callee has to provide method/function  overload with a structure containing all arguments. But in theory Phobos could provide a mixin/template to make this task a one liner.
>
> In my opinion this fits much nicer than introducing a new attribute.
>
> Kind regards
> Andre

I 100% support that. Relying on struct initialization is both the easiest and safest way to go in my opinion:

0) as a reminder the idea is that today you can do that:

    struct S { int a, int b=42 }
    void f(S args);

    S args = { .b=43 };   // yeah, useful C legacy!
    f(args);

   but there's currently no way to directly initialize that struct in the f() call.

1) it's already there. All problems have already been solved, the code is there with reordering, default values, order of evaluation etc. Struct initialization already works, just not in-place.

2) it's as backward compatible as it can be: as long as the calle provides a function that takes a struct as argument it'll work. It'll work with C code, it'll work with C++ code, it'll work without @named, it'll just work. It's just structs, cleverly used.

3) the only thing needed is to finally close that in-place struct initialization DIP.

I'd much rather have that than introducing new attributes and duplicating code (since, as I said, such code is already existing for partial structs initialization).

On Sunday, 17 February 2019 at 13:44:09 UTC, Cym13 wrote:
>     S args = { .b=43 };   // yeah, useful C legacy!

I obviously meant:   S args = { b: 43 };

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

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

On Sunday, 17 February 2019 at 13:44:09 UTC, Cym13 wrote:
> On Saturday, 16 February 2019 at 12:41:01 UTC, Andre Pany wrote:
>> [...]
>
> I 100% support that. Relying on struct initialization is both the easiest and safest way to go in my opinion:
>
> 0) as a reminder the idea is that today you can do that:
>
>     struct S { int a, int b=42 }
>     void f(S args);
>
>     S args = { .b=43 };   // yeah, useful C legacy!
>     f(args);
>
>    but there's currently no way to directly initialize that struct in the f() call.
>
> 1) it's already there. All problems have already been solved, the code is there with reordering, default values, order of evaluation etc. Struct initialization already works, just not in-place.
>
> 2) it's as backward compatible as it can be: as long as the calle provides a function that takes a struct as argument it'll work. It'll work with C code, it'll work with C++ code, it'll work without @named, it'll just work. It's just structs, cleverly used.

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".

>
> 3) the only thing needed is to finally close that in-place struct initialization DIP.
>
> I'd much rather have that than introducing new attributes and duplicating code (since, as I said, such code is already existing for partial structs initialization).

So it probably could be reused?