DIP 1020--Named Parameters--Community Review Round 1

Paul Backus snarwin at gmail.com
Sun Mar 31 14:32:54 UTC 2019


On 3/31/19 8:33 AM, Mike Parker wrote:
> This is the feedback thread for the first round of Community Review for
> DIP 1020, "Named Parameters":

Some remarks:

1. The angle-bracket syntax is an odd choice. There's no precedent in D
(or, as far as I know, any other language) for angle-brackets indicating
that names are significant, so anyone encountering this syntax for the
first time is going to have to look it up to know what it means. If
they're clever, and speak English well enough to know that "<>" are
called "angle brackets", they'll still have to avoid getting sidetracked
by the "Template Comparison" [1] page in order to find the page in the
language spec that covers named parameters (which hopefully includes the
words "angle brackets" itself...).

Ironically, I think this version of named parameters would be a much
better fit for an attribute like @named or @keyword than the one in DIP
1019. Not only would such an attribute convey its meaning better to an
unfamiliar reader than angle brackets, it would also be much easier to
search for.

2. The feature that allows named parameters of templates to be accessed
as though they were members of the template requires explicit
justification for its inclusion. It is (a) orthogonal to the rest of the
proposal, (b) possible to implement in user code, either by hand or as a
mixin template, and (c) an unavoidable source of namespace pollution.

The interaction with eponymous templates is also non-obvious. Naively,
one might expect the eponymous member and the named-argument members to
be siblings, but in the case of (e.g.) `struct Foo<T> {}`, the member
for T is actually *inside* the eponymous member.

I'm sure there are good reasons for proposing this feature, but those
reasons need to be stated directly in the DIP itself, not left for the
reader to infer.

3. The "Future Proposals" section is very weak. Adding ordering
restrictions after the fact would be a breaking change, and the
hypothetical "API Alias Parameters" feature is difficult to understand
and of no obvious use without further elaboration. I would recommend
removing this section from the DIP entirely.

[1] https://dlang.org/articles/template-comparison.html


More information about the Digitalmars-d mailing list