Feedback Thread: DIP 1032--Function Pointer and Delegate Parameters...--Final Review

[Mathias LANG]

On Monday, 3 August 2020 at 11:33:47 UTC, Mike Parker wrote:
> This is the feedback thread for the Final Review of DIP 1032, 
> "Function Pointer and Delegate Parameters Inherit Attributes 
> from Function".

Realized I sent my review to the discussion thread.
Here's the original: 
https://forum.dlang.org/post/bfijfbmgoezkjmkuxttu@forum.dlang.org

Copy pasting it here for reference:
===================================

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.