This is the discussion thread for the first round of Community Review of DIP 1032, "Function pointers and Delegate Parameters Inherit Attributes from Function":

https://github.com/dlang/DIPs/blob/0c99bd854302ade3e6833080410e9050fddec346/DIPs/DIP1032.md

The review period will end at 11:59 PM ET on April 17, or when I make a post declaring it complete. Discussion in this thread may continue beyond that point.

Here in the discussion thread, you are free to discuss anything and everything related to the DIP. Express your support or opposition, debate alternatives, argue the merits, etc.

However, if you have any specific feedback on how to improve the proposal itself, then please post it in the feedback thread. The feedback thread will be the source for the review summary I write at the end of this review round. I will post a link to that thread immediately following this post. Just be sure to read and understand the Reviewer Guidelines before posting there:

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

And my blog post on the difference between the Discussion and Feedback threads:

https://dlang.org/blog/2020/01/26/dip-reviews-discussion-vs-feedback/

Please stay on topic here. I will delete posts that are completely off-topic.

On Friday, 3 April 2020 at 10:30:33 UTC, Mike Parker wrote:

>
> However, if you have any specific feedback on how to improve the proposal itself, then please post it in the feedback thread. The feedback thread will be the source for the review summary I write at the end of this review round. I will post a link to that thread immediately following this post.

The Feedback thread is here:

https://forum.dlang.org/post/tkosvxedhztfjxsxtkdm@forum.dlang.org

The inheritance rationale also applies to aggregates btw, which if done would obviate the "by default" changes btw.

Once this change is made, the aggregate status quo will stand out even more as a weird inconsistency.

Moreover, what if you need to invert the attributes? Yes, the same thing comes up again.

nothrow
int makeNothrow(void delegate() dg) {
    try {
      dg();
      return 0;
    } catch(Exception e) {
      return e.toErrorCode();
    }
}


Obviously, a nothrow dg there defeats the purpose of that function... so how do you tell it you want a throws dg?

There's an easy fix here, something we've wanted for ages, but this change makes it all the more necessary.

On Friday, 3 April 2020 at 12:58:24 UTC, Adam D. Ruppe wrote:
> Obviously, a nothrow dg there defeats the purpose of that function... so how do you tell it you want a throws dg?

That can be accomplished with the alias trick described in "Breaking Changes and Deprecations".

On Friday, 3 April 2020 at 10:30:33 UTC, Mike Parker wrote:
> This is the discussion thread for the first round of Community Review of DIP 1032, "Function pointers and Delegate Parameters Inherit Attributes from Function":
>
> https://github.com/dlang/DIPs/blob/0c99bd854302ade3e6833080410e9050fddec346/DIPs/DIP1032.md
>

Already gave my review on it: https://github.com/dlang/DIPs/pull/170#pullrequestreview-294073723
I would very much welcome a way to express a relationship between the delegate's attributes and the function's attributes. But this piece of magic ? No thanks. The change itself is bad on its own, and only marginally useful if the `lazy` case is the only one considered.

On 4/3/2020 5:58 AM, Adam D. Ruppe wrote:
> so how do you tell it you want a throws dg?

This is covered in the DIP.

Continuing the discussion from https://forum.dlang.org/post/r688sq$2ism$1@digitalmars.com

> Delegate/functionpointer parameters do not infer safe/nogc/pure/nothrow from their use inside the function.

No of course they do not. But S.foo infers it's attributes from the function body. S.foo is not a template function, so I would assume this passes to the delegate.

Are you suggesting that:

struct S(T)
{
   T delegate() _dg;
   void foo(T delegate() dg) { _dg = dg; }
}

behaves differently than:

struct S
{
   int delegate() _dg;
   void foo(int delegate() dg) @safe pure @nogc nothrow {_dg = dg;}
}

?

in other words, in both cases, you can call from @safe pure @nogc nothrow context, but the parameter in the first case is T delegate() (with no attributes), but the second, the parameter becomes int delegate() @safe pure nothrow @nogc?

There needs to be a discussion of templates in the DIP, especially when template attribute inference can and can not affect the delegate attribute requirements.

-Steve

On Friday, 3 April 2020 at 10:30:33 UTC, Mike Parker wrote:
> This is the discussion thread for the first round of Community Review of DIP 1032, "Function pointers and Delegate Parameters Inherit Attributes from Function":
>
> https://github.com/dlang/DIPs/blob/0c99bd854302ade3e6833080410e9050fddec346/DIPs/DIP1032.md
>
> The review period will end at 11:59 PM ET on April 17, or when I make a post declaring it complete. Discussion in this thread may continue beyond that point.
>
> Here in the discussion thread, you are free to discuss anything and everything related to the DIP. Express your support or opposition, debate alternatives, argue the merits, etc.
>
> However, if you have any specific feedback on how to improve the proposal itself, then please post it in the feedback thread. The feedback thread will be the source for the review summary I write at the end of this review round. I will post a link to that thread immediately following this post. Just be sure to read and understand the Reviewer Guidelines before posting there:
>
> https://github.com/dlang/DIPs/blob/master/docs/guidelines-reviewers.md
>
> And my blog post on the difference between the Discussion and Feedback threads:
>
> https://dlang.org/blog/2020/01/26/dip-reviews-discussion-vs-feedback/
>
> Please stay on topic here. I will delete posts that are completely off-topic.

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.

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; }

> On Friday, 3 April 2020 at 10:30:33 UTC, Mike Parker wrote:
> > This is the discussion thread for the first round of Community Review of DIP 1032, "Function pointers and Delegate Parameters Inherit Attributes from Function":
> > 
> > https://github.com/dlang/DIPs/blob/0c99bd854302ade3e6833080410e9050fddec346/DIPs/DIP1032.md
> > 
> > The review period will end at 11:59 PM ET on April 17, or when I make a post declaring it complete. Discussion in this thread may continue beyond that point.
> > 
> > Here in the discussion thread, you are free to discuss anything and everything related to the DIP. Express your support or opposition, debate alternatives, argue the merits, etc.
[...]

I echo Dukc's concerns from the other thread, that this DIP seems to be approaching the problem in the wrong way.

What I often find myself needing is not that delegates inherit attributes from the function it's passed to, but rather the reverse: that the *function* inherits the attributes of the passed-in delegate.

The whole point of a delegate is to insert arbitrary code into a function at certain points, so usually one wants maximum freedom for the caller to pass in a delegate with any set of attributes.  Why limit what the caller can do?  If the caller wants to pass in a @system delegate, then so be it, let him do whatever he wants.  From the POV of a library author, I want my code to be maximally reusable, so as much as possible I don't want to limit what my callers can pass to me.

What *I*, the function implementor, am concerned with is that *my* code, that is, the function body besides the calls to the delegate, conforms to certain attributes, such as @safe.  By doing so, I make it possible for @safe callers to use my function -- if they pass in a @safe delegate, then my function should be @safe.  If the delegate they pass in is @system, then obviously my function should also be @system.

I've almost never found a need for my function to impose restrictions on a passed-in delegate -- the delegate is the caller's problem, I don't care what they do with it.  I want my function to accomodate both @safe and @system delegates, and I want my function to be usable with both @safe and @system callers (the former case conditional upon the delegate being @safe).  Why would I want to limit what kind of delegates the caller passes to me?  If the delegate does something bad, that's the caller's problem, not mine.  My concern is only that my code accomodates callers with any attribute sets, whether they can actually call me with that attribute set is up to them -- by ensuring the delegate they give me conforms to said attributes.  It's not my function's responsibility to enforce what the caller does with the delegate; it's the caller's responsibility to give me a delegate with the attributes that the caller wants from my function.

IOW, it should be the *function* that inherits attributes from the passed-in delegate, not the other way round as proposed by this DIP.


T

-- 
When solving a problem, take care that you do not become part of the problem.

On 4/3/2020 3:07 PM, Steven Schveighoffer wrote:
> Continuing the discussion from https://forum.dlang.org/post/r688sq$2ism$1@digitalmars.com
> 
>> Delegate/functionpointer parameters do not infer safe/nogc/pure/nothrow from their use inside the function.
> 
> No of course they do not. But S.foo infers it's attributes from the function body. S.foo is not a template function, so I would assume this passes to the delegate.
> 
> Are you suggesting that:
> 
> struct S(T)
> {
>     T delegate() _dg;
>     void foo(T delegate() dg) { _dg = dg; }
> }
> 
> behaves differently than:
> 
> struct S
> {
>     int delegate() _dg;
>     void foo(int delegate() dg) @safe pure @nogc nothrow {_dg = dg;}
> }
> 
> ?

Yes. (Otherwise the inference would have to be iterative, which I'd really like to avoid.)

> 
> in other words, in both cases, you can call from @safe pure @nogc nothrow context, but the parameter in the first case is T delegate() (with no attributes), but the second, the parameter becomes int delegate() @safe pure nothrow @nogc?
> 
> There needs to be a discussion of templates in the DIP, especially when template attribute inference can and can not affect the delegate attribute requirements.

Your example is a good one, and I'll include it.