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.
