Discussion Thread: DIP 1032--Function Pointers and Delegate Parameters...--Final Review

[Avrina]

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.