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

[Walter Bright]

On 4/3/2020 4:05 PM, Jonathan Marler wrote:
> If this were implemented, I'd prefer for it to be "opt-in" with an attribute 
> such as @inherit 
> (https://forum.dlang.org/post/plvqxehkjzxkvhsacjwp@forum.dlang.org), however, 
> even if it was opt-in, I'm still not a huge fan of this feature.  Reason being 
> that I favor making code "easier to read" rather than "easier to write".  Adding 
> a new "attribute inheritance" semantic, whether implicitly or explicitly adds 
> cognitive burden to the reader.  You now have to have extra knowledge about when 
> attributes are inherited, whereas with the status quo, you don't have to think 
> about it because all attributes are explicit.  And even if we make it opt in, 
> now you have to learn a new syntax and/or attribute and how it works.  For me 
> the benefit doesn't really justify the added complexity.

We can't solve every problem with adding ever more attributes. I kinda regard 
every attribute we wind up adding as an admission of defeat.

The idea is the user won't have to think about the delegate attributes in the 
most common cases, it will "just work".

> P.S. What about delegate types defined inside functions? Would they also inherit 
> the functions attributes? @safe pure nothrow void foo() { alias D = void 
> delegate(); D d; }

I should think so, otherwise how could the function call it?