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.

wait!
why should be error here?
when named args doesn't set - use usual overload rules.

> void draw( @named Rect rect );
> void draw( @named Circle oval );

> Shape shape = Line( ... ); // can be Rect/Circle too with same result
> Rect oval = Rect( ... );
> Circle rect = Circle( ... );

> draw( shape ); // ERROR. no method for Shape
> draw( rect ); // OK. draw( Circle <- rect ). rect is Circle in my case
> draw( oval ); // OK. draw( Rect <- oval ).

> draw( oval: shape ); // ERROR: struct/class Shape is not good for any overloads

> draw( oval: oval ); // ERROR: oval is Rect and no named arg "oval" for method that receive Rect.

> draw( oval: rect ); // OK. draw( Circle <- rect )

> draw( rect: shape ); // ERROR. No overloads for Shape

> draw( rect: rect ); // ERROR. rect is Circle and method draw( Circle ) doens't have arg "rect"

> draw( rect: oval ); // OK. draw( Rect <- oval );

On Thursday, 12 September 2019 at 12:15:57 UTC, a11e99z wrote:
> On Thursday, 12 September 2019 at 11:46:46 UTC, rikki cattermole wrote:
>> On 12/09/2019 11:29 PM, Yuxuan Shui wrote:

naming args is not mandatory.
using names depends from user of lib not from lib itself or compiler.

On Thursday, 12 September 2019 at 12:19:51 UTC, a11e99z wrote:
> On Thursday, 12 September 2019 at 12:15:57 UTC, a11e99z wrote:
>> On Thursday, 12 September 2019 at 11:46:46 UTC, rikki cattermole wrote:
>>> On 12/09/2019 11:29 PM, Yuxuan Shui wrote:
>
> naming args is not mandatory.
> using names depends from user of lib not from lib itself or compiler.

but when overload rules points to method that haven't any of named args that user choose - ERROR, user should understand that method that user probably want to invoke (expect) is not method that compiler will invoke - and this is ERROR that user should fix.

On Thursday, 12 September 2019 at 12:06:47 UTC, rikki cattermole wrote:
> On 12/09/2019 11:50 PM, Yuxuan Shui wrote:
>> On Thursday, 12 September 2019 at 11:46:46 UTC, rikki cattermole wrote:
>>> [...]
>> 
>> 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.

Sorry, I don't think I understand your answer. My question has nothing to do with templates.

On Thursday, 12 September 2019 at 12:19:51 UTC, a11e99z wrote:
> On Thursday, 12 September 2019 at 12:15:57 UTC, a11e99z wrote:
>> On Thursday, 12 September 2019 at 11:46:46 UTC, rikki cattermole wrote:
>>> On 12/09/2019 11:29 PM, Yuxuan Shui wrote:
>
> naming args is not mandatory.
> using names depends from user of lib not from lib itself or compiler.

In DIP 1020, naming arguments is mandatory.

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.

The development of Phobos is slow as a snail pace, even when it comes to refactoring. Again we are talking about old libraries that backwards compatible and that are hardly updated. That will certainly will kill the adoption rate.

Alex

On 13/09/2019 1:44 AM, Yuxuan Shui wrote:
> On Thursday, 12 September 2019 at 12:06:47 UTC, rikki cattermole wrote:
>> On 12/09/2019 11:50 PM, Yuxuan Shui wrote:
>>> On Thursday, 12 September 2019 at 11:46:46 UTC, rikki cattermole wrote:
>>>> [...]
>>>
>>> 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.
> 
> Sorry, I don't think I understand your answer. My question has nothing to do with templates.

To get the functionality you asked about, I had to use templates.

To support overloading on named parameters would require invasive changes and adding a new mangling sequence. Things I want to avoid.

a11e99z asked a similar question under your own in this part of the thread tree. Same answer.

On Thursday, 12 September 2019 at 13:44:52 UTC, Paul Backus wrote:
> On Thursday, 12 September 2019 at 12:19:51 UTC, a11e99z wrote:
>> On Thursday, 12 September 2019 at 12:15:57 UTC, a11e99z wrote:
>>> On Thursday, 12 September 2019 at 11:46:46 UTC, rikki cattermole wrote:
>>>> On 12/09/2019 11:29 PM, Yuxuan Shui wrote:
>>
>> naming args is not mandatory.
>> using names depends from user of lib not from lib itself or compiler.
>
> In DIP 1020, naming arguments is mandatory.

this is not good.

it was not good cuz method can be called with mixing named and positional args
> func( 1, z: 3, y: 2, 4 ); // and comma is float-dot for some human langs
and optional can be mixed(before) with required args
> void func( int one, float two =2, string three ) { }

and now is not good from other side:
u can not call method without naming args when @named exists in definition.

"out of the frying pan into the fire"

I dont like such named args.

---------------------
I like C# naming more and more:
- defaulted/optional args only in the end of args list (function definition).
- naming args is not mandatory (function call).
- named args only after positional/required args not intermixing (func call).
- order for named args doesn't matter (func call).
- required/positional/non-defaulted args should be assigned (func call).
- and assigning arg more than once is error.

> void func( int one, float two =5, string three ); // ERROR. optional before required.
> void func( int one, float two, string three, int four = 123, float five = 3.14 );

> func( 1, 2, "3", 4, 5 ); // OK
> func( 1, five: 2.72, 2, four: 321, three: "hello" ); // ERROR. named before positional
> func( 1, five: 3e8, four: 4, three: "3", two: 2 ); // OK
> func( 1, 2, four: 321 ); // ERROR. required "three" is not assigned
> func( 1, three: "hello", two: 2 ); // OK
> func( 1, 2, three: "hello", two: 2 ); // ERROR. "two" assigned twice
---------------------

what the reason do mandatory naming for @named args?
arg names will also be involved in choosing the right method along with overloading and templates and UFCS?

On Thursday, 12 September 2019 at 14:36:09 UTC, rikki cattermole wrote:
> On 13/09/2019 1:44 AM, Yuxuan Shui wrote:
>> On Thursday, 12 September 2019 at 12:06:47 UTC, rikki cattermole wrote:
>>> On 12/09/2019 11:50 PM, Yuxuan Shui wrote:
>>>> On Thursday, 12 September 2019 at 11:46:46 UTC, rikki cattermole wrote:
>
> To support overloading on named parameters would require invasive changes and adding a new mangling sequence. Things I want to avoid.
>

I am not considering named template arguments now cuz me with templates is not like a fish in water.

@named will be only in source code or .di files.
how and why @named should be involved in mangled names and method selection?

why the following rules are bad:
- naming is not mandatory and
- method are selecting as usual by overload/UFCS rules and
  need to check that named args satisfy @named args in found func definition.
  in other case probably user thought about another function.

----------------------

sux.

do what u want.
but please don't add mandatory @named to functions that can be used in lambdas - map, fold, take, another hundred functions too. cuz it will be shitty named mess.

On 13/09/2019 2:37 AM, a11e99z wrote:
> arg names will also be involved in choosing the right method along with overloading and templates and UFCS?

No they will not be.

If they were, it would effect function and symbol overloading which would require mangling changes. It is a very invasive set of changes that would cause problems in implementation. It is not something that should be considered unless you are a compiler developer with an implementation that is tested.