On 11/09/2019 5:53 PM, Lionello Lunesu wrote:
> On Tuesday, 10 September 2019 at 09:06:23 UTC, Mike Parker wrote:
>> This is the feedback thread for the second round of Community Review for DIP 1020, "Named Parameters":
>>
>> https://github.com/dlang/DIPs/blob/c723d8f4e3ac2d5bcaf8cdff87e1507f09669ca6/DIPs/DIP1020.md 
>>
> 
> I can't seem to find the rationale for the necessity of a parameter syntax? As a library writer, when would I annotate a parameter with `@named`? Does adding `@named` *require* naming the parameter? The DIP notes a new trait to find named vs unnamed parameters, but is that the *reason* for the new syntax or a handy side effect? Couldn't the regular UDA trait be used (or extended) to find `@named` or any other UDA for that matter?

A named parameter must include a name yes. Good catch.

The trait(s) is listed under "Supporting Syntax". It supports the rest of the DIP and while useful I wouldn't call it a handy side effect or a reason for design choices were made.

Its a simple way that does not require much in the way of changes to the language or would take very long to implement to get the named parameter names on a template (for e.g. functions that is a side effect for consistency reasons).

> If I assume there's a good reason for having this opt-in for parameters, wouldn't this then require a lot of churn for library writers, with diffs adding just `@named` to parameters and no other code changes?

Nobody is forced to use it.

I would recommend to incrementally add it, as the API designs allow for it, and not just add it because it exists.

On Wednesday, 11 September 2019 at 14:33:37 UTC, rikki cattermole wrote:
> On 11/09/2019 5:53 PM, Lionello Lunesu wrote:
>> On Tuesday, 10 September 2019 at 09:06:23 UTC, Mike Parker wrote:
>>> This is the feedback thread for the second round of Community Review for DIP 1020, "Named Parameters":
>>>
>>> https://github.com/dlang/DIPs/blob/c723d8f4e3ac2d5bcaf8cdff87e1507f09669ca6/DIPs/DIP1020.md
>>>
>> 
>> I can't seem to find the rationale for the necessity of a parameter syntax? As a library writer, when would I annotate a parameter with `@named`? Does adding `@named` *require* naming the parameter? The DIP notes a new trait to find named vs unnamed parameters, but is that the *reason* for the new syntax or a handy side effect? Couldn't the regular UDA trait be used (or extended) to find `@named` or any other UDA for that matter?
>
> A named parameter must include a name yes. Good catch.
>
> The trait(s) is listed under "Supporting Syntax". It supports the rest of the DIP and while useful I wouldn't call it a handy side effect or a reason for design choices were made.
>
> Its a simple way that does not require much in the way of changes to the language or would take very long to implement to get the named parameter names on a template (for e.g. functions that is a side effect for consistency reasons).
>
>> If I assume there's a good reason for having this opt-in for parameters, wouldn't this then require a lot of churn for library writers, with diffs adding just `@named` to parameters and no other code changes?
>
> Nobody is forced to use it.
>
> I would recommend to incrementally add it, as the API designs allow for it, and not just add it because it exists.
What good is named arguments if around 90% libraries don't support it?

On 12/09/2019 3:12 AM, 12345swordy wrote:
> What good is named arguments if around 90% libraries don't support it?

I won't put a percentage on the number of libraries that will not support it. Over time the number should decrease as people get use to it and find ways to use it to suit their style.

On Wednesday, 11 September 2019 at 05:15:04 UTC, rikki cattermole wrote:
> On 11/09/2019 6:47 AM, Jonathan Marler wrote:
>> Sorry in advance for the bikeshedding, but using the @ symbol just looks ugly to me. How about using 'public' instead of '@named'?
>> 
>>      void foo(@named bool log, @named bool goFast);
>> Vs.
>>      void foo(public bool log, public bool goFast);
>
> I considered this quite some time ago.
>
> It works for templates, but it does not work for functions.
>

Why wouldn't it work for functions?

On Wednesday, 11 September 2019 at 16:00:13 UTC, rikki cattermole wrote:
> On 12/09/2019 3:12 AM, 12345swordy wrote:
>> What good is named arguments if around 90% libraries don't support it?
>
> I won't put a percentage on the number of libraries that will not support it. Over time the number should decrease as people get use to it and find ways to use it to suit their style.

That is an assertion, with no evidence. Your DIP needs to take the account of libraries that are hardly updated. Why should the user suffer when the libraries aren't updated or refused to update their functions with named arguments even when it seems very reasonable at the time to the user. You can't just suggest that the user to fork every library out there in order to used named arguments!

I repeat: This "public api" issue is overblown. This issue you try to avoid still will still exist even you did make it opt-in.

I can't advocate this with a straight face in game development.

-Alex

On 12/09/2019 4:08 AM, Jonathan Marler wrote:
> On Wednesday, 11 September 2019 at 05:15:04 UTC, rikki cattermole wrote:
>> On 11/09/2019 6:47 AM, Jonathan Marler wrote:
>>> Sorry in advance for the bikeshedding, but using the @ symbol just looks ugly to me. How about using 'public' instead of '@named'?
>>>
>>>      void foo(@named bool log, @named bool goFast);
>>> Vs.
>>>      void foo(public bool log, public bool goFast);
>>
>> I considered this quite some time ago.
>>
>> It works for templates, but it does not work for functions.
>>
> 
> Why wouldn't it work for functions?

Syntactically and semantically there is no reason for it to not work.

It comes down to personal preference. To me it means that there is some sort of semantic associated with functions and their named parameters like there is with templates when there isn't.

On Wednesday, 11 September 2019 at 16:00:13 UTC, rikki cattermole wrote:
> On 12/09/2019 3:12 AM, 12345swordy wrote:
>> What good is named arguments if around 90% libraries don't support it?
>
> I won't put a percentage on the number of libraries that will not support it. Over time the number should decrease as people get use to it and find ways to use it to suit their style.

Given that adding @named to an existing parameter would be a breaking change, it's unlikely any existing libraries--including existing Phobos modules--will be updated to support named arguments. Only new libraries written after DIP 1020 is implemented and released will be in a good position to take advantage of it.

This is a major downside to DIP 1020 compared to both Walter's proposal and DIP 1019 ("Named Arguments Lite"), which would work seamlessly with existing code.

On 9/11/2019 12:18 AM, rikki cattermole wrote:
> But I need to confirm with you before I do this, is this for the replacement of in place struct initialization syntax?
> 
> If so I want to solve that, but I need to ask you how you would want it done. Since it touches upon .init, it makes me a little concerned because of dragons.

I'm planning to replace:

  struct S { int a, b; }

  S s = { 1, 2 };

with:

  S s = S(1, 2);

D is almost there already, but is missing the named parameter feature to go all the way.

I'm looking at other ways as well to unify and thereby simplify D.

On 12/09/2019 11:01 AM, Walter Bright wrote:
> On 9/11/2019 12:18 AM, rikki cattermole wrote:
>> But I need to confirm with you before I do this, is this for the replacement of in place struct initialization syntax?
>>
>> If so I want to solve that, but I need to ask you how you would want it done. Since it touches upon .init, it makes me a little concerned because of dragons.
> 
> I'm planning to replace:
> 
>    struct S { int a, b; }
> 
>    S s = { 1, 2 };
> 
> with:
> 
>    S s = S(1, 2);
> 
> D is almost there already, but is missing the named parameter feature to go all the way.
> 
> I'm looking at other ways as well to unify and thereby simplify D.

Okay so it is what I'm thinking.

I currently have three solutions to support in place struct initialization with DIP 1020.

I would like to know which direction you would like me to go.

1. Syntax magic
2. Generate a constructor (which bypasses restrictions)
3. Hope somebody else figures out how to do it, but state that it is supported

I'm currently leaning towards 2 but it would mean researching what restrictions are in place, why they are in place and make sure I'm not breaking anything in the type system.

We would end up having two constructors generated, if the default constructor is not @disabled or if no constructors are defined. I'm not sure which restriction (or both).

struct Foo {
	int x, y;

	// generated
	this(@named int x = int.init,
		@named int y = int.init) {
		this.x = x;
		this.y = y;
	}

	// generated
	this(int x, int y=int.init) {
		this.x = x;
		this.y = y;
	}
}

On Wednesday, 11 September 2019 at 23:01:32 UTC, Walter Bright wrote:
> On 9/11/2019 12:18 AM, rikki cattermole wrote:
>> But I need to confirm with you before I do this, is this for the replacement of in place struct initialization syntax?
>> 
>> If so I want to solve that, but I need to ask you how you would want it done. Since it touches upon .init, it makes me a little concerned because of dragons.
>
> I'm planning to replace:
>
>   struct S { int a, b; }
>
>   S s = { 1, 2 };
I don't like this style too.

>   S s = S( a=1, b=2 );
with named args it will be more readable.

but more than this I want next:
> // dont need "new" cuz its not needed for structs
> // and not needed for classes too - they are in GC by default

> auto form = AppWindow {
>     title = "main window",
>     children = [ // child-list
>       TextBox {
>         text = "Hello World!",
>         font = Font { family="Times Roman", height=24 },
>       },
>       Button {
>         text = "Press me!",
>         tilt = Color.Red,
>         click ~= parent.close() // delegate list
>       }
>     ]
>   };

probably it better to do not through constructor but with some kind of init-list:
> opAssignInitList( /* what here? tuple? */ ) = default;
that assign automatically to all fields and properties
and just check that no one field/prop assigned more than once