On 2/6/20 4:06 PM, Lim 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"
> 
> 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

I think this is ambiguous:

template Example(int b)
{
   enum Example = b + 5;
}

enum b = 5;
auto x = true ? Example!b:1;

or maybe:

case Example!b:

It could be worked out if one examines the whole expression/statement, but I think we're better off avoiding support for such things.

Note that existing templates don't allow operators when omitting parentheses.

-Steve

On Thursday, 6 February 2020 at 21:06:38 UTC, Lim wrote:
> Can we still omit the parentheses if it is one token long?

And another example of this issue:

template Example(alias x, int y = 0) { ... }

// assume x defined before

is(Example!x : int) { ... }

Note: Although DIP 88 and DIP 1020 give some examples on using Named Arguments with single parameter template (all with parentheses). Nothing is mentioned on whether parentheses are required in this situation.

According to current Spec: "If the TemplateArgument is one token long, the parentheses can be omitted", all two examples I showed are legal. As the indentifier tokens are not the same thing as TemplateArgument tokens:

+TemplateNamedArgument:
+    Identifier : TemplateArgument
+    TemplateArgument

Thus, the single-token parameter use case should be regulated in DIP 1030.

On Thursday, 6 February 2020 at 21:37:11 UTC, Steven Schveighoffer wrote:
> It could be worked out if one examines the whole expression/statement, but I think we're better off avoiding support for such things.
>
> Note that existing templates don't allow operators when omitting parentheses.
>
> -Steve

Yep, that's what I mean. We should make it impossible or have a predictable behavior. Unfortunately, this case was not mentioned in DIP 1030.

On Thursday, 6 February 2020 at 21:41:33 UTC, Lim wrote:
> According to current Spec: "If the TemplateArgument is one token long, the parentheses can be omitted", all two examples I showed are legal.

One token, not one argument.
`a:b` and alike are three tokens long.
See https://dlang.org/spec/lex.html#tokens

On 2/6/20 4:46 PM, Lim wrote:
> On Thursday, 6 February 2020 at 21:37:11 UTC, Steven Schveighoffer wrote:
>> It could be worked out if one examines the whole expression/statement, but I think we're better off avoiding support for such things.
>>
>> Note that existing templates don't allow operators when omitting parentheses.
>>
> 
> Yep, that's what I mean. We should make it impossible or have a predictable behavior. Unfortunately, this case was not mentioned in DIP 1030.

I'm not sure it needs mentioning, as long as we are going to continue to enforce the current rules (no operators are included unless you use parentheses). Allowing colons as part of the no-parentheses template arg would be a difference that required a grammar change. As the DIP isn't changing that grammar (it's here: https://dlang.org/spec/grammar.html#TemplateSingleArgument), we shouldn't need to discuss it.

-Steve

On Thursday, 6 February 2020 at 21:58:19 UTC, Steven Schveighoffer wrote:
> https://dlang.org/spec/grammar.html#TemplateSingleArgument), we shouldn't need to discuss it.

I'm sold.

On 2/6/2020 1:37 PM, Steven Schveighoffer wrote:
> It could be worked out if one examines the whole expression/statement, but I think we're better off avoiding support for such things.

Note that C++ stepped into a similar mess when picking < > for template arguments.

We're not going that way.

On Wednesday, February 5, 2020 11:08:59 PM MST Mike Parker via Digitalmars-d wrote:
> This is the feedback thread for the first round of Community Review for DIP 1030, "Named Arguments":
>
> https://github.com/dlang/DIPs/blob/44b0d4ec0da6a2e797ede748fb1e81cd6db1037 1/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.

Well, I'll say again that I don't like the idea of having named arguments in the language, because it makes the parameter names part of the API, resulting in yet more bikeshedding and yet another thing that can't be changed without breaking existing code. Once in a while, named arguments may be useful, but for the most part, they're useful because a function has way too many parameters, in which case, the function should have been designed differently.

Unfortunately, since it's Walter who created the DIP, and a number of people do like the idea of named arguments, I expect that some form of this will make it in, but I still think that it's a bad idea.

- Jonathan M Davis

Replying to Timon's post on the feedback thread:

On 2/6/20 10:49 PM, Timon Gehr wrote:
> This introduces syntax like:
>
> import std.typecons;
> alias t=AliasSeq!(c:1, a:2, b:3); // valid according to DIP
> void foo(int a,int b,int c){
>      writeln(a," ",b," ",c);
> }
>
> void main(){
>      foo(t);
> }

Does it? AliasSeq's template parameter (singular) is named TList, not a, b, or c.

So I would expect this to fail to compile.

This does bring up a valid point though. The DIP talks about variadic parameters, but template variadic parameters actually have a name.

So what does this mean? Is it valid?

AliasSeq!(TList: 1, 2, 3)

-Steve

On 2/7/20 12:00 AM, Steven Schveighoffer wrote:

> This does bring up a valid point though. The DIP talks about variadic parameters, but template variadic parameters actually have a name.

So do typesafe variadics. I think the DIP needs to be more explicit here with what it means.

-Steve