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