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

[Mathias LANG]

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.