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