DIP 1019--Named Arguments Lite--Community Review Round 1

Cym13 cpicard at openmailbox.org
Sun Feb 17 13:44:09 UTC 2019


On Saturday, 16 February 2019 at 12:41:01 UTC, Andre Pany wrote:
>
> With the struct initialization DIP there will come also named 
> arguments complicity.
>
> https://github.com/wilzbach/DIPs/blob/b1283b455b635d7dcbc2c871d2aa47cc67190059/DIPs/DIP1xxx-sw.md
>
> Yes, the callee has to provide method/function  overload with a 
> structure containing all arguments. But in theory Phobos could 
> provide a mixin/template to make this task a one liner.
>
> In my opinion this fits much nicer than introducing a new 
> attribute.
>
> Kind regards
> Andre

I 100% support that. Relying on struct initialization is both the 
easiest and safest way to go in my opinion:

0) as a reminder the idea is that today you can do that:

     struct S { int a, int b=42 }
     void f(S args);

     S args = { .b=43 };   // yeah, useful C legacy!
     f(args);

    but there's currently no way to directly initialize that 
struct in the f() call.

1) it's already there. All problems have already been solved, the 
code is there with reordering, default values, order of 
evaluation etc. Struct initialization already works, just not 
in-place.

2) it's as backward compatible as it can be: as long as the calle 
provides a function that takes a struct as argument it'll work. 
It'll work with C code, it'll work with C++ code, it'll work 
without @named, it'll just work. It's just structs, cleverly used.

3) the only thing needed is to finally close that in-place struct 
initialization DIP.

I'd much rather have that than introducing new attributes and 
duplicating code (since, as I said, such code is already existing 
for partial structs initialization).


More information about the Digitalmars-d mailing list