DIP 1030--Named Arguments--Community Review Round 1 Feedback

[Manu]

On Wed, Feb 5, 2020 at 10:10 PM Mike Parker via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
>
> This is the feedback thread for the first round of Community
> Review of DIP 1030, "Named Arguments".
>
> ===================================
> **THIS IS NOT A DISCUSSION THREAD**
>
> Posts in this thread must adhere to the feedback thread rules
> outlined in the Reviewer Guidelines (and listed at the bottom of
> this post).
>
> https://github.com/dlang/DIPs/blob/master/docs/guidelines-reviewers.md
>
> That document also provides guidelines on contributing feedback
> to a DIP review. Please read it before posting here. If you would
> like to discuss this DIP, please do so in the discussion thread:
>
> https://forum.dlang.org/post/ngjihdoyluxrikjzcxhk@forum.dlang.org
>
> ==================================
>
> You can find DIP 1030 here:
>
> https://github.com/dlang/DIPs/blob/44b0d4ec0da6a2e797ede748fb1e81cd6db10371/DIPs/DIP1030.md
>
> The review period will end at 11:59 PM ET on February 20, or when
> I make a post declaring it complete. Feedback posted to this
> thread after that point may be ignored.
>
> At the end of Round 1, if further review is deemed necessary, the
> DIP will be scheduled for another round of Community Review.
> Otherwise, it will be queued for the Final Review and Formal
> Assessment.
>
> ==================================
> Posts in this thread that do not adhere to the following rules
> will be deleted at the DIP author's discretion:
>
> * All posts must be a direct reply to the DIP manager's initial
> post, with only two exceptions:
>
>      - Any commenter may reply to their own posts to retract
> feedback contained in the original post
>
>      - The DIP author may (and is encouraged to) reply to any
> feedback solely to acknowledge the feedback with agreement or
> disagreement (preferably with supporting reasons in the latter
> case)
>
> * Feedback must be actionable, i.e., there must be some action
> the DIP author can choose to take in response to the feedback,
> such as changing details, adding new information, or even
> retracting the proposal.
>
> * Feedback related to the merits of the proposal rather than to
> the contents of the DIP (e.g., "I'm against this DIP.") is
> allowed in Community Review (not Final Review), but must be
> backed by supporting arguments (e.g., "I'm against this DIP
> because..."). The supporting arguments must be reasonable.
> Obviously frivolous arguments waste everyone's time.
>
> * Feedback should be clear and concise, preferably listed as
> bullet points (those who take the time to do an in-depth review
> and provide feedback in the form of answers to the questions in
> this document will receive much gratitude). Information
> irrelevant to the DIP or is not provided in service of clarifying
> the feedback is unwelcome.
>

Named arguments breaks this very important pattern:

auto wrapper(alias origFun)(Parameters!origFun args)
{
  // special sauce
  return origFun(args);
}

Calling with named arguments can not apply to `wrapper` as it does to `origFun`.
Any library that makes use of any such wrapper may not work in
conjunction with named arguments.

As an exercise to the reader; show an implementation of `wrapper`
which preserves argument names and default args... (hint: it's much
more complicated than you think)