On Sunday, 6 March 2016 at 20:35:49 UTC, Jacob Carlborg wrote:
On 2016-03-06 18:35, Seb wrote:
Hey all,
I wanted to relive the discussion on named arguments and ping
for its
current status.
There is a bunch of examples to show how needed a unified
solution for
this problem is, let me give you one from phobos [2].
```
// I want to allow downsizing
iota(10).sliced!(Yes.replaceArrayWithPointer,
Yes.allowDownsize)(4);
```
There is of course the alternative solution that an author
overloads his
function to the utmost, but this results in complexity and
duplicated
code (see e.g. redBlackTree in phobos [3]).
Currently the best solution AFAICT is to use a struct to pass
such
flags, like
```
struct Options{int x; int y=1; int z=2;}
auto fun(Options options)
{
return options.x + options.y + options.z;
}
Options options = {x: 4, z: 3};
auto a=fun(options);
```
There are also other workarounds as discussed in [1] (e.g.
with CTFE
string analysis [4]).
I general there two solutions to this problem
1) get true named parameters support in D (probably
complicated)
2) allow struct inits in functions - e.g. fun({x: 4})
For 2) Jacob Carlborg has proposed something similar three
years ago. In
his case he proposed anonymous structs which might be more
generally
applicable, however just created the struct seems easier and
allows more
It doesn't seem that complicated to me as the compiler already
knows the
type of the argument.
Using structs is not ideal, because one can't require
parameters, but
this can be solved by having those parameters as normal ones
like
`sliced(4, {allowDownsize: true})` and it creates some maybe
unnecessary
overhead.
However it is probably the easiest solution right now.
What are your thoughts on this issue?
I think the simplest solution is to allow struct member
initializer in all places a struct literal is accepted [1].
[1] https://issues.dlang.org/show_bug.cgi?id=15692
+100
This can also pave the way for tuple literals, e.g.:
// nothing new, ordinary struct member init
Point2 point = { x: 3, y: 4 };
// auto variables are deduced to be tuples
auto namedTuple = { x: 3, y: 4 }; // a.k.a anonymous classes in C#
auto plainTuple = { 10, "hi", 3.14 }; // See also DIP32
Which I don't think will cause ambiguity with delegates:
auto tuple3 = { getInt() }; tuple
auto tuple3 = { getInt(); }; lambda
// unambiguous (disallow delegates that contain only CommaExpr):
auto tuple4 = { getInt(), getString(), getDouble() };
