This is the feedback thread for the Final Review of DIP 1032, "Function Pointer and Delegate Parameters Inherit Attributes from Function".

===================================
**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/ubcwhqxyjizccoekpgbw@forum.dlang.org

==================================

You can find DIP 1032 here:

https://github.com/dlang/DIPs/blob/5675676cfb21a69cfd6eda033c53356ee2275fd1/DIPs/DIP1032.md

The review period will end at 11:59 PM ET on August 17, or when I make a post declaring it complete. Feedback posted to this thread after that point may be ignored.

At the end of the Final Review, the DIP will be forwarded to the language maintainers for 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.

On Monday, 3 August 2020 at 11:33:47 UTC, Mike Parker wrote:
> This is the feedback thread for the Final Review of DIP 1032, "Function Pointer and Delegate Parameters Inherit Attributes from Function".

Realized I sent my review to the discussion thread.
Here's the original: https://forum.dlang.org/post/bfijfbmgoezkjmkuxttu@forum.dlang.org

Copy pasting it here for reference:
===================================

This DIP does not add any new feature to the language: It moves a
restriction from one place (the delegate call within the calling
function) to another (the moment the calling function is passed a
delegate).

But it only do so inconsistently & incompletely: as soon as the
delegate is aliased, the restriction moves back to its original
location (the call)! Likewise, templates will behave differently
and are completely unaffected.
This makes the new behavior at odds with existing
functionalities: usually, templates functions, parameters, or
auto functions are the ones getting type inference, while regular
D functions allow to specify exactly what is expected.

Additionally it makes some previously rejected code compiles, and
make some previously accepted code not compile anymore. However,
as stated in the first sentence, it doesn't allow new patterns or
idioms: any code that it would stop to reject could be trivially
changed (by adding the attributes) so it would be accepted. The
code that was previously valid and would not compile anymore can
also be fixed trivially, but requires obfuscation through an
`alias`.
In other words, this trades readability for ease of writing.

Now, those are tradeoffs that would make sense if the issue was
predominant. After all if the default makes much more sense in
almost all cases, then it wouldn't hurt readability (an example
of this is the default-initialization of variables).
However the DIP does not attempt to quantify the impact it will
have, so there's no argument in favor of it being a sensible
default. On the other hand, a quick search through druntime and
Phobos, along with my own experience, shows that:
- Aliased delegates are more common in druntime;
- Aliased delegates make a lot of sense as soon as the delegate
has a few parameters;
- Phobos wouldn't benefit from this DIP, as it is heavily
templated;
- Most functions that accept delegates are unattributed;

 From my experience, the last point is the most important. There
are two main reasons why attributes aren't applied to functions
that accept delegates: either the function is virtual, and the
author didn't want to burden users with arbitrary limitations, or
the author didn't want to put unnecessary restriction on the
people passing delegates, (e.g. `Throwable.toString()`) and thus
couldn't put attributes on his/her function because that would
require putting attributes on the delegate.

That last part should resonate with anyone having worked with
delegates heavily: the inability to derive a function's
attributes from a delegate's means function ends up being
unattributed if one cannot template the delegate. This is the
most common problem with delegates at the moment, and having the
ability to apply a function's attributes to a parameter won't
help when you actually want to apply a parameter's attributes to
a function.

This DIP came about because I ran into annoying instances in druntime/phobos where pure functions were being passed pure delegates as parameters, but were being rejected by the compiler because the parameter was un-attributed. I fixed them, so it is not a surprise that phobos/druntime do not exhibit examples of those issues.

I also anticipate this feature will be convenient for when `lazy` is eliminated and arguments will be implicitly convertible to delegates.

The readability/writeability issue is more important than you suggest; people don't like writing attribute soup. Things that preserve the value of attributes while not requiring people to write them are good.

The downside of this proposal that most concerns me is the breaking of existing code.

On Monday, 3 August 2020 at 11:33:47 UTC, Mike Parker wrote:

>
> The review period will end at 11:59 PM ET on August 17, or when I make a post declaring it complete. Feedback posted to this thread after that point may be ignored.
>

This review round is complete. Thanks for the feedback.