Feedback Thread: DIP 1032--Function pointers and Delegate Parameters...--Community Review Round 1

[Jonathan Marler]

On Friday, 3 April 2020 at 10:31:12 UTC, Mike Parker wrote:
> This is the feedback thread for the first round of Communnity 
> Review of DIP 1032, "Function pointers 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/ovllntpiebixbtrbiuxj@forum.dlang.org
>
> ==================================
>
> You can find DIP 1032 here:
>
> https://github.com/dlang/DIPs/blob/0c99bd854302ade3e6833080410e9050fddec346/DIPs/DIP1032.md
>
> The review period will end at 11:59 PM ET on April 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 this review round, the DIP will be moved into the 
> Post-Community Round 1 state. Significant revisions resulting 
> from this review round may cause the DIP manager to require 
> another round of Community Review, otherwise the DIP will be 
> queued for the Final Review.
>
> ==================================
> 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.


I also want to point out that the "Breaking Changes and 
Deprecations" section is incorrect.

    > It is possible that a parameter declaration may require that 
a delegate or function pointer parameter have fewer attributes 
than the function itself. This would only be possible if the 
delegate or function pointer was never called, but was ignored or 
simply stored elsewhere.

It's possible that you want the function or delegate pointer to 
have fewer attributes even when you are calling it.

In my other comment I gave the "nothrow" example, where the 
function itself is nothrow but the function/delegate points can 
throw.  So I wanted to make sure that this use case is also 
addressed in this section.

Another use case off the top of my head is "pure".  You could be 
a pure function yourself, and call non-pure function/delegate 
pointers so long as they are inside debug blocks.

I'm sure there are other cases, the author has oversimplified the 
breaking changes here.