www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Feedback Thread: DIP 1032--Function Pointer and Delegate

reply Mike Parker <aldacron gmail.com> writes:
This is the feedback thread for the Final Review of DIP 1032, 
"Function Pointer and Delegate Parameters Inherit Attributes from 
Function".

===================================
**THIS IS NOT A DISCUSSION THREAD**

Posts in this thread must adhere to the feedback thread rules 
outlined in the Reviewer Guidelines (and listed at the bottom of 
this post).

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

That document also provides guidelines on contributing feedback 
to a DIP review. Please read it before posting here. If you would 
like to discuss this DIP, please do so in the discussion thread:

https://forum.dlang.org/post/ubcwhqxyjizccoekpgbw forum.dlang.org

==================================

You can find DIP 1032 here:

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

The review period will end at 11:59 PM ET on August 17, or when I 
make a post declaring it complete. Feedback posted to this thread 
after that point may be ignored.

At the end of the Final Review, the DIP will be forwarded to the 
language maintainers for Formal Assessment.

==================================
Posts in this thread that do not adhere to the following rules 
will be deleted at the DIP author's discretion:

* All posts must be a direct reply to the DIP manager's initial 
post, with only two exceptions:

     - Any commenter may reply to their own posts to retract 
feedback contained in the original post

     - The DIP author may (and is encouraged to) reply to any 
feedback solely to acknowledge the feedback with agreement or 
disagreement (preferably with supporting reasons in the latter 
case)

* Feedback must be actionable, i.e., there must be some action 
the DIP author can choose to take in response to the feedback, 
such as changing details, adding new information, or even 
retracting the proposal.

* Feedback related to the merits of the proposal rather than to 
the contents of the DIP (e.g., "I'm against this DIP.") is 
allowed in Community Review (not Final Review), but must be 
backed by supporting arguments (e.g., "I'm against this DIP 
because..."). The supporting arguments must be reasonable. 
Obviously frivolous arguments waste everyone's time.

* Feedback should be clear and concise, preferably listed as 
bullet points (those who take the time to do an in-depth review 
and provide feedback in the form of answers to the questions in 
this document will receive much gratitude). Information 
irrelevant to the DIP or is not provided in service of clarifying 
the feedback is unwelcome.
Aug 03 2020
next sibling parent reply Mathias LANG <geod24 gmail.com> writes:
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.
Aug 14 2020
parent Walter Bright <newshound2 digitalmars.com> writes:
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 also anticipate this feature will be convenient for when `lazy` is eliminated 
and arguments will be implicitly convertible to delegates.

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.

The downside of this proposal that most concerns me is the breaking of existing 
code.
Aug 17 2020
prev sibling parent Mike Parker <aldacron gmail.com> writes:
On Monday, 3 August 2020 at 11:33:47 UTC, Mike Parker wrote:


 The review period will end at 11:59 PM ET on August 17, or when 
 I make a post declaring it complete. Feedback posted to this 
 thread after that point may be ignored.


This review round is complete. Thanks for the feedback.
Aug 18 2020