DIP 1019--Named Arguments Lite--Community Review Round 1
Yuxuan Shui
yshuiv7 at gmail.com
Sun Feb 17 17:14:57 UTC 2019
On Sunday, 17 February 2019 at 13:44:09 UTC, Cym13 wrote:
> On Saturday, 16 February 2019 at 12:41:01 UTC, Andre Pany wrote:
>> [...]
>
> 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.
Sure, but it has the exactly same property as @named: it's opt-in.
Yes, maybe you can do it with a one-liner (I don't know how.
There doesn't seem to be a way to retrieve parameter names from a
function), but that can't be easier than adding "@named".
>
> 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).
So it probably could be reused?
More information about the Digitalmars-d
mailing list