On 02/04/2019 3:09 AM, Atila Neves wrote:
> There are known reasons why using angle brackets complicates lexing (cough! C++! cough!), so the syntax choice is odd. Is there a particular reason why the usage suggested here avoids the issues?

As far as I'm aware, we should have no problems with adapting dmd-fe to support it.

Of course I could have missed something (either in dmd or outside). So it would be good to have somebody else double check that statement.

On 3/31/19 8:53 AM, Andre Pany wrote:
> I still have the opinion we should go for in place struct initialization first. Here we get named parameters implicit without adding a complete new syntax. I also do not like the new syntax <>.
> Leveraging what inplace struct initialization syntax gives us, seems a lot more reasonable in my opinion.
> 
> Kind regards
> Andre

I keep feeling like the in-place struct initialization proposal plus the syntax sugar described in its "Bonus 1"[1] would be perfect. It strikes me as very D-ish: clever, simple to explain, doesn't conflict with existing features, and allows the call-side things we want from named parameters like omitting arguments and/or providing them in any order, per existing rules for static initialization of structs [2].

[1]: https://github.com/dlang/DIPs/blob/b1283b455b635d7dcbc2c871d2aa47cc67190059/DIPs/DIP1xxx-sw.md#bonus-1-function-calls-with-the-struct-argument-as-sole-parameter
[2]: https://dlang.org/spec/struct.html#static_struct_init

On 4/1/19 10:41 AM, rikki cattermole wrote:
> On 02/04/2019 3:09 AM, Atila Neves wrote:
>> There are known reasons why using angle brackets complicates lexing (cough! C++! cough!), so the syntax choice is odd. Is there a particular reason why the usage suggested here avoids the issues?
> 
> As far as I'm aware, we should have no problems with adapting dmd-fe to support it.
> 
> Of course I could have missed something (either in dmd or outside). So it would be good to have somebody else double check that statement.

I don't see one either, but then a lot of very smart people didn't see that a<b>(c) could mean both (a < b) > (c) and (a<b>)(c).

Much more recently, many folks, even after having learned from the experience just mentioned, didn't realize that a.operator<=>(b) could mean both (a.operator<=) > (b) and (a.operator<=>)(b).

At any rate, this is unlikely to win a beauty contest:

void fun(<bool a=b>c>);

Also, it seems named parameters without reordering is like a wedding without music.

On Monday, 1 April 2019 at 13:21:48 UTC, rikki cattermole wrote:

> Unnamed arguments must remain in the same order they are declared in.
>
> Named arguments must remain in the same order they are declared in, but they may be inserted in between unnamed arguments giving a partial reordering.

That's the part that is going to cause major trouble for someone new to the language.

Suppose you have this function:

foo(int v, int w, int x, int y, int z)

Then the call

foo(3, 4, 5, 6, 7)

is easy to understand, even if you have to know which order the arguments appear. But make x, y, and z named parameters, and you have

foo(3, 4, x=5, y=6, z=7)
foo(3, x=5, 4, y=6, z=7)
foo(3, x=5, y=6, 4, z=7)
foo(3, x=5, y=6, z=7, 4)

all evaluating to the same thing, and somehow the programmer is supposed to know that the 4 is mapped to the second argument in every call. This is the kind of thing that would make someone give up on D after just a few minutes. The only way it can work to rearrange the mapping of parameters from the function call to the function itself is if the parameter being moved is named. This is a simple example. If you had several named and several unnamed parameters it would lead to a lot of confusion.

On Monday, 1 April 2019 at 19:41:25 UTC, bachmeier wrote:
> On Monday, 1 April 2019 at 13:21:48 UTC, rikki cattermole wrote:
>
>> [...]
>
> That's the part that is going to cause major trouble for someone new to the language.
>
> Suppose you have this function:
>
> foo(int v, int w, int x, int y, int z)
>
> Then the call
>
> foo(3, 4, 5, 6, 7)
>
> is easy to understand, even if you have to know which order the arguments appear. But make x, y, and z named parameters, and you have
>
> foo(3, 4, x=5, y=6, z=7)
> foo(3, x=5, 4, y=6, z=7)
> foo(3, x=5, y=6, 4, z=7)
> foo(3, x=5, y=6, z=7, 4)
>
> all evaluating to the same thing, and somehow the programmer is supposed to know that the 4 is mapped to the second argument in every call. This is the kind of thing that would make someone give up on D after just a few minutes. The only way it can work to rearrange the mapping of parameters from the function call to the function itself is if the parameter being moved is named. This is a simple example. If you had several named and several unnamed parameters it would lead to a lot of confusion.

Whats the big issue with named parameters, why cant D have them with the same restriction as C#?

foo(3, 4, x=5, y=6, z=7) works
foo(3, x=5, 4, y=6, z=7) does'nt, because every paremeter after a named one has to be a named parameter

On Monday, 1 April 2019 at 19:41:25 UTC, bachmeier wrote:
> [snip]
> all evaluating to the same thing, and somehow the programmer is supposed to know that the 4 is mapped to the second argument in every call. This is the kind of thing that would make someone give up on D after just a few minutes. The only way it can work to rearrange the mapping of parameters from the function call to the function itself is if the parameter being moved is named. This is a simple example.

In R, if you have
f <- function(x, y, z) { x + 2*y + 3*z}
and call
f(z=1, 2, 3)
the result is 11.

I don't know if that's any easier or not, but I can definitely see how people would find a lot of these examples confusing.

On Monday, 1 April 2019 at 20:36:47 UTC, arturg wrote:
> Whats the big issue with named parameters, why cant D have them with the same restriction as C#?
>
> foo(3, 4, x=5, y=6, z=7) works
> foo(3, x=5, 4, y=6, z=7) does'nt, because every paremeter after a named one has to be a named parameter

+1 It's the same rule as in Python and others, and it works.  Mixing positional/named parameters makes the call harder to read.  (Think quick: which positional parameter does the 4 in the example refer to?)

Reordering named parameters is useful because if the parameters are named, that probably means the names are more semantic than the ordering.  Having to remember an arbitrary ordering just makes life more difficult.

On Sunday, 31 March 2019 at 12:33:56 UTC, Mike Parker wrote:
> This is the feedback thread for the first round of Community Review for DIP 1020, "Named Parameters":
>
> https://github.com/dlang/DIPs/blob/39dbbbe5e4618abd4c4b41eb0edd16547858ddf5/DIPs/DIP1020.md
>

Well. Do we have no other choice than that syntax?
Happy about no-reordering here.

On Monday, 1 April 2019 at 14:41:20 UTC, rikki cattermole wrote:
> On 02/04/2019 3:09 AM, Atila Neves wrote:
>> There are known reasons why using angle brackets complicates lexing (cough! C++! cough!), so the syntax choice is odd. Is there a particular reason why the usage suggested here avoids the issues?
>
> As far as I'm aware, we should have no problems with adapting dmd-fe to support it.
>
> Of course I could have missed something (either in dmd or outside). So it would be good to have somebody else double check that statement.

You already have to deal with the case of variadic function definitions, so why not just extend the syntax?

I.e., in this declaration

void foo(int a, int b, ..., int c);

c must be a named argument, even without any special decorators.  In that case the ... argument acts as a delimiter.  So all you need is rules for separating positional arguments from named arguments for non-variadic functions.

On Mon, Apr 01, 2019 at 11:11:33PM +0000, sarn via Digitalmars-d wrote:
> On Monday, 1 April 2019 at 20:36:47 UTC, arturg wrote:
> > Whats the big issue with named parameters, why cant D have them with the same restriction as C#?
> > 
> > foo(3, 4, x=5, y=6, z=7) works
> > foo(3, x=5, 4, y=6, z=7) does'nt, because every paremeter after a
> > named one has to be a named parameter
> 
> +1 It's the same rule as in Python and others, and it works.  Mixing positional/named parameters makes the call harder to read.  (Think quick: which positional parameter does the 4 in the example refer to?)
> 
> Reordering named parameters is useful because if the parameters are named, that probably means the names are more semantic than the ordering.  Having to remember an arbitrary ordering just makes life more difficult.

Yeah, having named and unnamed parameters in mixed order doesn't make sense to me; it's just like having non-default arguments following default arguments -- makes code needlessly complicated and hard to read. It should be just a simple boolean state: the initial segment of an argument list is positional, with zero or more arguments, and the remainder of the argument list is named, with zero or more arguments. Once a named argument is encountered it's no longer grammatical to have a positional argument.

Something along these lines:

	ArgumentList ::= PositionalArgs NamedArgs
		;

	PositionalArgs ::= <empty list>
		| <expression>
		| <expression> "," PositionalArgs
		;

	NamedArgs ::= <empty list>
		| <identifier> "=" <expression>
		| <identifier> "=" <expression> "," NamedArgs
		;


T

-- 
Heads I win, tails you lose.