DIP 1020--Named Parameters--Community Review Round 1

[H. S. Teoh]

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.