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

Joseph Rushton Wakeling joseph.wakeling at webdrake.net
Sun Mar 3 09:36:32 UTC 2019


On Wednesday, 27 February 2019 at 18:51:40 UTC, Daniel N wrote:
> It would be great indeed, but insufficient.
>
> At least I can't find a reasonble struct based solution which 
> handle default arguments correctly.
>
> struct dim {
>   uint w=5;
>   uint h=5;
> }
>
> void foo(dim d={w:10, h:10}){}
> void bar(dim d={w:20, h:20}){}
>
> foo({w:50}); // h should default to 10 but it likely will be 5
> bar({w:50}); // h should default to 20 but it likely will be 5

I wonder if you have a real-world example of this requirement 
(same named parameters but different requirements for defaults)?  
I ask because it seems like the best way to address the concern 
is likely to be contingent on the particular use case.

The example given considers the input as a type encoding the set 
of parameter names and types, with default values as something 
extraneous.  It feels like that's the conceptual problem: the 
input type should encode parameter names, types, and defaults all 
together.

In other words, `foo` and `bar` should have different struct 
types (with different default values to their fields) as input.

Clunky and maybe a bit boilerplate-y?  Yes, but much less 
intrusive than introducing a syntax change that has significant 
impact on the maintainability of much already existing code.

Note that this would be simpler from a developer point of view if 
it was possible to declare "anonymous" structs in place in the 
function declarations, i.e.:

     int foo (struct { int w = 10; int h = 10; });
     int bar (struct { int w = 20; int h = 20; });

... which combined with the earlier suggestion would also be a 
fairly natural extension of existing struct syntax.


More information about the Digitalmars-d mailing list