Named arguments via struct initialization in functions

[Idan Arye via Digitalmars-d]

On Wednesday, 9 March 2016 at 10:06:25 UTC, Martin Tschierschke 
wrote:
> 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.

String symbols are Ruby's(and many Lisps', and maybe some other, 
less popular languages) way to do untyped enums and untyped 
structs. It's a dynamically typed languages thing and has no room 
in statically typed languages like D. D mimics dynamic typing to 
some extent by creating types on the fly with it's powerful 
templates mechanism - but a new type still needs to be created. D 
is geared toward reflection on types at compile time, not towards 
type detection at run-time...

Allowing something like `auto params = [:y : 50, :x : 100]` won't 
really solve anything. It works nicely in Ruby, because Ruby has 
dynamic typing and with some syntactic sugar you get elegant 
syntax for dynamic structs. But in a structured language like D, 
you run into the problem that `[:y : 50, :x : 100] is an 
associative array with a determined type for it's values, so you 
can't do things like `[:y : 50, :x : "hello"]` - which greatly 
limits the usability of this syntax.