Named arguments via struct initialization in functions

[ZombineDev via Digitalmars-d]

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() };