On Sunday, 6 March 2016 at 17:35:38 UTC, 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?
On a side note: many templated functions are also complicated
and experiencing this issue, so it also might be worth to think
about this issue too ;-)
Cheers,
Seb
[1]
http://forum.dlang.org/post/[email protected]
[2] https://github.com/DlangScience/mir/issues/18
[3]
https://github.com/D-Programming-Language/phobos/pull/4041/files
[4]
https://github.com/timotheecour/dtools/blob/master/dtools/util/functional.d
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. Using a struct to define the
named arguments solves the signature problem, but the ambiguity
problem remains - it simply gets shifted from "which overload to
choose" to "which struct to choose".
The consensus here seems to be that ambiguous code should be
result in compilation errors(and that it should be easy for the
compiler to detect that the code is ambiguous!), and that if
structs are used to declare named arguments, then solving
overloading ambiguities should be done by constructing the struct
explicitly. Then everyone disagree regarding how structs should
be created explicitly with named fields.
I would like to suggest an idea that will allow solving
ambiguities without the need for new syntax(behind the syntax for
declaring and using named arguments), be consistent with existing
D features, and as a bonus provide a much nicer syntax:
Make it like variadic functions!
Declaring the named arguments variadically will be done by adding
`...` after a struct argument:
struct Options{int x; int y=1; int z=2;}
auto fun(Options options ...)
We'll need a syntax for specifying the arguments - but that's
more of a matter of taste than an actual technical problem, and
it's going to be bikeshedded over and over, so for the purpose of
describing my idea let's pick a Ruby-style `:`(because `=` will
break the rule of if-it-compiles-as-C-it-should-work-like-C):
fun(x: 4, z: 3);
I've promised you to solve ambiguity, right? Well, just like
regular variadic functions can be called with an explicit array,
named arguments variadic functions should also be callable with
an explicit struct:
Options options = {x: 4, z: 3};
fun(options);
Which brings us back to square one, right? Wrong! Because at this
point, it should be trivial to give structs a second default
constructor:
this(typeof(this) that ...) {
this = that;
}
(actual implementation may be more efficient and
robust(preferably a syntactic sugar for postblit), but you get
the idea). So now structs can be constructed with named
arguments, and ambiguities could be neatly solved with:
fun(Options(x: 4, z: 3));
P.S: If a struct-based solution is ever implemented for named
arguments, I do hope it'll support template inference, where a
simple PODS(Plain Old D Struct... sorry...) is automatically
created based on the supplied arguments' names and types(and
order!). UDA support for that could be nice too...
