Named arguments via struct initialization in functions

[Martin Tschierschke via Digitalmars-d]

On Tuesday, 8 March 2016 at 18:46:02 UTC, Chris Wright wrote:
> On Tue, 08 Mar 2016 13:52:09 +0000, Martin Tschierschke wrote:
>> What about this idea? A new word "as" or something similar. 
>> fun(ypos as y, xpos as x, radius as r); // different order!
>
> The syntax isn't an issue.
>
> There was one DIP about named parameters, but it was unpopular. 
> It didn't change *anything* about overload resolution; it only 
> had the compiler check that you provided arguments in the 
> correct order, even if they were all of the same type.
>
> Even if there were a DIP everyone liked, nobody is signing up 
> to implement it. DDMD is a little scary and not reflective of 
> good design in D (having been translated by machine from C++).
>
> I might take a look, but I probably won't have the time to 
> produce anything useful.

I have seen the "DIP about named parameters", and i liked the idea
of getting a easier to read code, because it gets more verbose.

My idea with the  "val as x" was to avoid the need to define the 
functions in a
different way. But as Idan Arye pointed out, it seems to be more 
difficult:

"As far as I understand, the main two problems with named 
arguments are overloading ambiguity and the fact that argument 
names are not part of the signature."

An other point on my wish list would be to allow string symbol 
notation
like in ruby. Than using hashes (AA) for parameters gets more 
convenient:

:symbol <= just short for => "symbol"

h[:y]= 50; h[:x] = 100; // <=> h["y"] = 50; h["x"] = 100

For calling a function:
auto params = [:y : 50, :x : 100] <=> auto params = ["y" : 50 , 
"x" : 100]

Especially when the code is nested in a string for mixin purpose. 
(vibe.d templates).

But maybe this crashes, because of
the ambiguity if no space after a ":" is used in this place:
auto hash = [ 1 :variable] meaning: auto hash = [ 1 : variable ]
not auto hash = [1 "variable" ] which would make no sense either.