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

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

Please, folks, let's keep it civil. We're all on the same team.

The review period will end at 11:59 PM ET on August 17, or when I make a post declaring it complete. Discussion in this thread may continue beyond that point.

Here in the discussion thread, you are free to discuss anything and everything related to the DIP. Express your support or opposition, debate alternatives, argue the merits, etc.

However, if you have any specific feedback on how to improve the proposal itself, then please post it in the feedback thread. The feedback thread will be the source for the review summary I write at the end of this review round. I will post a link to that thread immediately following this post. Just be sure to read and understand the Reviewer Guidelines before posting there:

https://github.com/dlang/DIPs/blob/master/docs/guidelines-reviewers.md

And my blog post on the difference between the Discussion and Feedback threads:

https://dlang.org/blog/2020/01/26/dip-reviews-discussion-vs-feedback/

Please stay on topic here. I will delete posts that are completely off-topic.

On Monday, 3 August 2020 at 11:32:57 UTC, Mike Parker wrote:

> However, if you have any specific feedback on how to improve the proposal itself, then please post it in the feedback thread. The feedback thread will be the source for the review summary I write at the end of this review round. I will post a link to that thread immediately following this post.

The feedback thread is here:

https://forum.dlang.org/post/axjajqhksecqdsercgmy@forum.dlang.org

As with Walter's other DIPs, nothing of substance has changed in the DIP. What more is there to discuss other than the exact same problems that have been discussed in the previous threads.

This change isn't substantial enough to warrant the breaking changes. It also adds some hacky workaround if you have a case that is part of the breaking changes. Which introduces complexity, not removing it as the rationale dictates. But no one is going to convince the DIP author of that, otherwise they wouldn't be writing this DIP.

What about case where delegate stored in class/struct field and calls in other place? May be inheriting attributes must be only for `scope` parameters?

On Monday, 3 August 2020 at 11:32:57 UTC, Mike Parker wrote:
> This is the discussion thread for the Final Review of DIP 1032, "Function Pointer and Delegate Parameters Inherit Attributes from Function":
>
> https://github.com/dlang/DIPs/blob/5675676cfb21a69cfd6eda033c53356ee2275fd1/DIPs/DIP1032.md
>
> Please, folks, let's keep it civil. We're all on the same team.
>
> The review period will end at 11:59 PM ET on August 17, or when I make a post declaring it complete. Discussion in this thread may continue beyond that point.
>
> Here in the discussion thread, you are free to discuss anything and everything related to the DIP. Express your support or opposition, debate alternatives, argue the merits, etc.
>
> However, if you have any specific feedback on how to improve the proposal itself, then please post it in the feedback thread. The feedback thread will be the source for the review summary I write at the end of this review round. I will post a link to that thread immediately following this post. Just be sure to read and understand the Reviewer Guidelines before posting there:
>
> https://github.com/dlang/DIPs/blob/master/docs/guidelines-reviewers.md
>
> And my blog post on the difference between the Discussion and Feedback threads:
>
> https://dlang.org/blog/2020/01/26/dip-reviews-discussion-vs-feedback/
>
> Please stay on topic here. I will delete posts that are completely off-topic.

Does anyone have any data about delegate use case? Personally I store delegates all the time and this dip sounds like it’ll make it very annoying to do so (if at all?).

Also I see that there was another proposal in the previous round that actual keeps the dip desired behavior but also allows storing of dips. And there was no agreement or dissagreement from the dip author after his misunderstanding of the alternative was corrected.

Or did I miss that maybe?

On Monday, 3 August 2020 at 11:32:57 UTC, Mike Parker wrote:
> This is the discussion thread for the Final Review of DIP 1032, "Function Pointer and Delegate Parameters Inherit Attributes from Function":
>
> https://github.com/dlang/DIPs/blob/5675676cfb21a69cfd6eda033c53356ee2275fd1/DIPs/DIP1032.md

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.

On Thursday, 6 August 2020 at 08:31:40 UTC, Mathias LANG wrote:
> 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 right here. This DIP is backwards.

I was expecting a response like this. Anyone not satisfied with his response? I know I'm not.

https://forum.dlang.org/post/rheuva$1ibo$1@digitalmars.com

On Monday, 17 August 2020 at 22:05:33 UTC, Walter Bright wrote:
> 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'm not sure what you mean here. What you are saying doesn't really make sense. The code you are talking about would be rejected 100% of the time, so I'm not sure how you came across a pure function that took an unattributed delegate and wasn't calling it.

void removePure(void delegate() dg) pure {
    dg(); // error can't call impure function
}

That could couldn't exist, or rather phobos/druntime wouldn't compile at all. So that PR wouldn't be merged at all.

Now maybe the function wasn't calling the delegate and you were making a change so that it does. And the function was already attributed pure.

struct Foo {
    void delegate() dg;
    void setDelegate(void delegate() pdg) pure {
        dg = pdg; // ok
        // dg();  // error
    }
}

I think this would fall under what Mr Lang was saying though, delegates are unattributed to ease the burdened on the user with being able to pass any attributed function they would like.

Anyways I am very curious and would what change you are talking about to druntime and phobos. You don't make very many PR to druntime nor phobos (especially to phobos, very few). I wasn't able to find any PR that makes the changes as you describe them in this post.

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

Why anticipate? I don't see this being any easier, you just need to add a few more attribute to a parameter. It takes no time at all, barely an inconvenience. Deprecate Lazy and if changes need to be made then make them then. There may be a better solution once people need to use delegates in place of lazy, there might even be a good library solution which this DIP does not investigate at all.

> 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.

People have been writing "attribute soups" since the beginning. You don't have to look very far to find functions attributed `@safe pure @nogc nothrow @property ref ...` and more attributes keep being adding see: @live. Large projects also adopted the best practice of not using `@safe nothrow @nogc:` and instead to label every function with the attributes it requires. As this makes the code more *readable*. It is very difficult to find `<attribute>:` in a large code base and try and figure out how it all ends up being computed.

If the goal is to reduce attribute bloat, there are better ways to achieve this that don't case breaking change. As well as that affect more than just delegates passed as a parameter.

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

It is important, but I'm surprised it is the most concerning to you considering how much code you were willing to break by making the default @safe. I think there's more concerning issues personally.


Anyways it feels like this DIP is just going to be plowed on through, and there's no major backlash this time that is going to stop it this time.

On Tuesday, 18 August 2020 at 13:21:33 UTC, Avrina wrote:
> I was expecting a response like this. Anyone not satisfied with ...
> 
>
> If the goal is to reduce attribute bloat, there are better ways to achieve this that don't case breaking change. As well as that affect more than just delegates passed as a parameter.
>

What would that be?

On Tuesday, 18 August 2020 at 20:03:41 UTC, aberba wrote:
> On Tuesday, 18 August 2020 at 13:21:33 UTC, Avrina wrote:
>> I was expecting a response like this. Anyone not satisfied with ...
>> 
>>
>> If the goal is to reduce attribute bloat, there are better ways to achieve this that don't case breaking change. As well as that affect more than just delegates passed as a parameter.
>>
>
> What would that be?

You can search the forums, lots of good ideas get brought up, no point in repeating them. Instead we get this broken as DIP cause Walter encountered who knows what situation that inconvenienced him.