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

On 12/09/2019 4:57 AM, Paul Backus wrote:
> 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.

There is no reason to believe that Phobos cannot be updated nor other existing libraries.

Deprecate old prototype.

Add new prototype.

Old prototype calls new prototype.

No more Flag nonsense and will be fairly easy to implement.

On 9/12/2019 12:09 AM, rikki cattermole wrote:
> 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.

Just use the syntax I proposed for named parameters. The feature will be disabled if the struct has constructor(s) for it, as now.

Kinda nothing to it.

On 12/09/2019 9:18 PM, Walter Bright wrote:
> On 9/12/2019 12:09 AM, rikki cattermole wrote:
>> 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.
> 
> Just use the syntax I proposed for named parameters. The feature will be disabled if the struct has constructor(s) for it, as now.
> 
> Kinda nothing to it.

Sweet, noted.

On Thursday, 12 September 2019 at 09:17:54 UTC, rikki cattermole wrote:
> On 12/09/2019 4:57 AM, Paul Backus wrote:
>> [...]
>
> There is no reason to believe that Phobos cannot be updated nor other existing libraries.
>
> Deprecate old prototype.
>
> Add new prototype.
>
> Old prototype calls new prototype.

Does that essentially mean we are going to rename all the functions?

>
> No more Flag nonsense and will be fairly easy to implement.

Dumb question: @named parameters are ignored in overload resolution, so in this example:

void draw(@named Circle shape);
void draw(@named Rectangle shape);

Is a call to draw:

draw(someShape);

always going to be a compilation error?

On 12/09/2019 11:25 PM, Yuxuan Shui wrote:
> On Thursday, 12 September 2019 at 09:17:54 UTC, rikki cattermole wrote:
>> On 12/09/2019 4:57 AM, Paul Backus wrote:
>>> [...]
>>
>> There is no reason to believe that Phobos cannot be updated nor other existing libraries.
>>
>> Deprecate old prototype.
>>
>> Add new prototype.
>>
>> Old prototype calls new prototype.
> 
> Does that essentially mean we are going to rename all the functions?

Of course not.

Overloading of symbols is a great thing ;)

We only need to do it incrementally for functions/templates where it makes sense. Not everything would benefit from named parameters.

E.g.

void func(int something, int flag = 0)

becomes

deprecated("Use named arguments version")
void func(int something, int flag) {
	func(something, flag: flag);
}

void func(int something, @named int flag = 0)

On 12/09/2019 11:29 PM, Yuxuan Shui wrote:
> Dumb question: @named parameters are ignored in overload resolution, so in this example:
> 
> void draw(@named Circle shape);
> void draw(@named Rectangle shape);
> 
> Is a call to draw:
> 
> draw(someShape);
> 
> always going to be a compilation error?

Yes.

Because you didn't use a named argument.

These would have been valid declarations that would match that function call:

void draw(Circle shape);
void draw(Rectangle shape);

In this example you didn't need named parameters.
Since the variable name of the calling body should be descriptive enough to tell you that it is a circle/rectangle.

On Thursday, 12 September 2019 at 11:46:46 UTC, rikki cattermole wrote:
> On 12/09/2019 11:29 PM, Yuxuan Shui wrote:
>> Dumb question: @named parameters are ignored in overload resolution, so in this example:
>> 
>> void draw(@named Circle shape);
>> void draw(@named Rectangle shape);
>> 
>> Is a call to draw:
>> 
>> draw(someShape);
>> 
>> always going to be a compilation error?
>
> Yes.
>
> Because you didn't use a named argument.
>
> These would have been valid declarations that would match that function call:
>
> void draw(Circle shape);
> void draw(Rectangle shape);
>
> In this example you didn't need named parameters.
> Since the variable name of the calling body should be descriptive enough to tell you that it is a circle/rectangle.

Ah, sorry. I meant to write draw(shape: someShape).

On 12/09/2019 11:50 PM, Yuxuan Shui wrote:
> On Thursday, 12 September 2019 at 11:46:46 UTC, rikki cattermole wrote:
>> On 12/09/2019 11:29 PM, Yuxuan Shui wrote:
>>> Dumb question: @named parameters are ignored in overload resolution, so in this example:
>>>
>>> void draw(@named Circle shape);
>>> void draw(@named Rectangle shape);
>>>
>>> Is a call to draw:
>>>
>>> draw(someShape);
>>>
>>> always going to be a compilation error?
>>
>> Yes.
>>
>> Because you didn't use a named argument.
>>
>> These would have been valid declarations that would match that function call:
>>
>> void draw(Circle shape);
>> void draw(Rectangle shape);
>>
>> In this example you didn't need named parameters.
>> Since the variable name of the calling body should be descriptive enough to tell you that it is a circle/rectangle.
> 
> Ah, sorry. I meant to write draw(shape: someShape).

In that case, two methods:

1. void draw(Shape)(@named Shape shape) { draw(shape); }

2. void draw(Shape:Circle)(@named Shape shape) { draw(shape); }

The second is better because of validating the parameter type, but does require one per type. Assuming I remember this particular bit of templates correctly.

I had to assume that drawing has to be specific to the type passed in and that the draw function will be concrete (can be virtual). But that shouldn't be a problem.