This is the feedback thread for the first round of Community Review for DIP 1030, "Named Arguments":

https://github.com/dlang/DIPs/blob/44b0d4ec0da6a2e797ede748fb1e81cd6db10371/DIPs/DIP1030.md

Here in the discussion thread, you are free to discuss anything and everything related to the DIP. Express your support or opposition, debate alternatives, argue the merits... in other words, business as usual.

However, if you have any specific feedback for how to improve the the proposal itself, then please post it in the feedback thread. The feedback thread will be the source for the review summary I write at the end of this review round. I will post a link to that thread immediately following this post. Just be sure to read and understand the Reviewer Guidelines before posting there:

https://github.com/dlang/DIPs/blob/master/docs/guidelines-reviewers.md

The review period will end at 11:59 PM ET on February 20, or when I make a post declaring it complete. Discussion in this thread may continue beyond that point.

At the end of Round 1, if further review is deemed necessary, the DIP will be scheduled for another round of Community Review. Otherwise, it will be queued for the Final Review and Formal Assessment.

Please stay on topic here. I will delete posts that are completely off topic.

On Thursday, 6 February 2020 at 06:08:59 UTC, Mike Parker wrote:

>
> However, if you have any specific feedback for how to improve the the proposal itself, then please post it in the feedback thread.

The feedback thread is here:

https://forum.dlang.org/post/bizqhxszbobynrimsgai@forum.dlang.org

On Thursday, 6 February 2020 at 06:08:59 UTC, Mike Parker wrote:
> This is the feedback thread for the first round of Community Review for DIP 1030, "Named Arguments":

What about UFSC + named arguments?

Andrea

On 2/6/20 4:39 AM, Andrea Fontana wrote:
> On Thursday, 6 February 2020 at 06:08:59 UTC, Mike Parker wrote:
>> This is the feedback thread for the first round of Community Review for DIP 1030, "Named Arguments":
> 
> What about UFSC + named arguments?

Responding to this and the one in the feedback thread.

My understanding is that UFCS works like this:

a.foo(...);

translates to:

foo(a, ...);

So if you follow that logic, the rules apply after that translation as if you called the function that way.

example:

void doStuff(int a, string b, double c) {}

3.doStuff(6.7, b: "ham") => doStuff(3, 6.7, b: ham) => error, no match (6.7 doesn't match type to b)

3.doStuff(c: 6.7, b: "ham") => doStuff(3, c: 6.7, b: ham) => OK, all parameters match

3.doStuff(a: 5, "ham", 6.7) => doStuff(3, a: 5, "ham", 6.7) => error, cannot match a twice

Might be a good point to add UFCS discussion to the DIP.

-Steve

On Thursday, 6 February 2020 at 15:30:40 UTC, Steven Schveighoffer wrote:
> On 2/6/20 4:39 AM, Andrea Fontana wrote:
> Might be a good point to add UFCS discussion to the DIP.
>
> -Steve

I wonder whether or not "(c: 3).doStuff(3,4);" could be useful... Probably it just adds some noise.

On Thu, Feb 06, 2020 at 05:03:06PM +0000, Andrea Fontana via Digitalmars-d wrote:
> On Thursday, 6 February 2020 at 15:30:40 UTC, Steven Schveighoffer wrote:
> > On 2/6/20 4:39 AM, Andrea Fontana wrote:
> > Might be a good point to add UFCS discussion to the DIP.
[...]
> I wonder whether or not "(c: 3).doStuff(3,4);" could be useful...
> Probably it just adds some noise.

IMO it not only adds noise, it opens the door for expanding UFCS far beyond its original charter. Because now, nothing stops you from doing this:

	struct A {}
	struct B {}
	struct C {}

	auto fun(A a, B b, C c) { ... }

	A a;
	B b;
	C c;

	(a: a).fun(b: b, c: c);
	(b: b).fun(a: a, c: c);
	(c: c).fun(a: a, b: b);

IOW, you can now pull out any arbitrary parameter from any function and do UFCS on it.  I honestly don't think this is a good idea, as it will open up whole cans o' worms esp. once it starts interacting with IFTI.


T

-- 
We are in class, we are supposed to be learning, we have a teacher... Is it too much that I expect him to teach me??? -- RL

On Thursday, 6 February 2020 at 17:03:06 UTC, Andrea Fontana wrote:
> On Thursday, 6 February 2020 at 15:30:40 UTC, Steven Schveighoffer wrote:
>> On 2/6/20 4:39 AM, Andrea Fontana wrote:
>> Might be a good point to add UFCS discussion to the DIP.
>>
>> -Steve
>
> I wonder whether or not "(c: 3).doStuff(3,4);" could be useful... Probably it just adds some noise.

Remmeber, UFCS is only tried when property lookup fails. Since `(c: 3).doStuff` is not a valid property access, it cannot possibly be a valid UFCS call.

On 2/6/2020 7:30 AM, Steven Schveighoffer wrote:
> Might be a good point to add UFCS discussion to the DIP.

Your analysis is correct and inevitable and doesn't need discussion in the DIP. It's another illustration why lowering is a good idea - it takes care of things like this renderubg further exposition and design work not necessary.

On Thursday, 6 February 2020 at 06:08:59 UTC, Mike Parker wrote:
> This is the feedback thread for the first round of Community Review for DIP 1030, "Named Arguments"

How about template arguments? Can we still omit the parentheses if it is one token long?

i.e., template Example(int a = 0, alias b, int c = 0) => Example!b:1

If the answer is yes, considering the following code:

template SomeTemplate(int a = 0, alias b, int c = 0)
{
    alias SomeTemplate = b;
}

const b = 2;
const c = 3;

switch(someInt)
{
    case 1: .. case SomeTemplate!b : c: writeln("we are in case"); break;
    default: writeln("we are in default"); goto c;
}


It's valid now and when someInt >= 3, "we are in default" and "we are in case" will both be printed.

According to the rule "If an Identifier is present, it matches the Parameter with the corresponding Identifier", when this DIP come into power, this code won't compile as there is no LabeledStatement Identifier named c.

Is this a potential compatibility issue? Or is there a misunderstanding of my interpretation of the new DIP?

On Thursday, 6 February 2020 at 21:06:38 UTC, Lim wrote:
> template SomeTemplate(int a = 0, alias b, int c = 0)

Should be:
template SomeTemplate(alias b, int c = 0)