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