This is the discussion thread for the Final Review of DIP 1033, "Implicit Conversion of Expressions to Delegates":

https://github.com/dlang/DIPs/blob/8e56fc593ece5c74f18b8eb68c3f9dcedf2396a7/DIPs/DIP1033.md

The review period will end at 11:59 PM ET on December 4, 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, 20 November 2020 at 07:29:21 UTC, Mike Parker wrote:

> 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.

The Feedback Thread is here:

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

On Fri, Nov 20, 2020 at 5:30 PM Mike Parker via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> This is the discussion thread for the Final Review of DIP 1033, "Implicit Conversion of Expressions to Delegates":
>
>
> https://github.com/dlang/DIPs/blob/8e56fc593ece5c74f18b8eb68c3f9dcedf2396a7/DIPs/DIP1033.md
>
> The review period will end at 11:59 PM ET on December 4, 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.
>

So, the thing that makes me nervous about this DIP, is that it may
substantially proliferate allocated closures.
I would want to have high confidence that people exclusively use `scope`
delegates, such that the closure can (will?/must?) be stack allocated.

In my experience, in the rare instance that I want to use a lazy parameter in the sorts of ways that might be affected by this DIP, it's usually in support of a fairly small optimisation, or a modest convenience in the API. Relative to that optimisation, if there's a risk of introducing a closure allocation, that would vastly out-weight the advantage by my judgement, and it's very easy for such allocations to go unnoticed. It's completely invisible.

I would appeal that this DIP be changed such that auto-delegates must be
`scope`, and non-scope delegates should require the user to specify a
non-scope delegate argument using typical delegate syntax, so that you can
plainly see it.
Without requiring `scope` delegates, the risk of hidden allocations is
extremely high, and it's almost certainly NOT what anybody would ever want
from a lazy argument, which is virtually always an INPUT argument, and
shouldn't be retained past the life of the call.

On Fri, Nov 20, 2020 at 6:06 PM Manu <turkeyman@gmail.com> wrote:

> On Fri, Nov 20, 2020 at 5:30 PM Mike Parker via Digitalmars-d < digitalmars-d@puremagic.com> wrote:
>
>> This is the discussion thread for the Final Review of DIP 1033, "Implicit Conversion of Expressions to Delegates":
>>
>>
>> https://github.com/dlang/DIPs/blob/8e56fc593ece5c74f18b8eb68c3f9dcedf2396a7/DIPs/DIP1033.md
>>
>> The review period will end at 11:59 PM ET on December 4, 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.
>>
>
> So, the thing that makes me nervous about this DIP, is that it may
> substantially proliferate allocated closures.
> I would want to have high confidence that people exclusively use `scope`
> delegates, such that the closure can (will?/must?) be stack allocated.
>
> In my experience, in the rare instance that I want to use a lazy parameter in the sorts of ways that might be affected by this DIP, it's usually in support of a fairly small optimisation, or a modest convenience in the API. Relative to that optimisation, if there's a risk of introducing a closure allocation, that would vastly out-weight the advantage by my judgement, and it's very easy for such allocations to go unnoticed. It's completely invisible.
>
> I would appeal that this DIP be changed such that auto-delegates must be
> `scope`, and non-scope delegates should require the user to specify a
> non-scope delegate argument using typical delegate syntax, so that you can
> plainly see it.
> Without requiring `scope` delegates, the risk of hidden allocations is
> extremely high, and it's almost certainly NOT what anybody would ever want
> from a lazy argument, which is virtually always an INPUT argument, and
> shouldn't be retained past the life of the call.
>

Another question that comes to mind, where the dip shows:

int delegate() dg = () { return 3; };

becomes:

int delegate() dg = () => 3;

become simply:

int delegate() dg = 3;

<https://github.com/dlang/DIPs/blob/8e56fc593ece5c74f18b8eb68c3f9dcedf2396a7/DIPs/DIP1033.md#prior-work>
This isn't an example of passing a lazy argument to a function that
receives a delegate; this demonstrates initialising a delegate variable
declaration. That seems off-topic to me, but it raises the question, does
this now work for delegates that receive parameters:

    int delegate(int x) dg = x + 10;

??
Are the parameters in scope for the expression to the right of the `=`?

This question doesn't really apply to the DIP, because a lazy argument delegate must necessarily have zero parameters... but the example shown here in the DIP raises questions along that associated path.

On Fri, Nov 20, 2020 at 6:18 PM Manu <turkeyman@gmail.com> wrote:

> On Fri, Nov 20, 2020 at 6:06 PM Manu <turkeyman@gmail.com> wrote:
>
>> On Fri, Nov 20, 2020 at 5:30 PM Mike Parker via Digitalmars-d < digitalmars-d@puremagic.com> wrote:
>>
>>> This is the discussion thread for the Final Review of DIP 1033, "Implicit Conversion of Expressions to Delegates":
>>>
>>>
>>> https://github.com/dlang/DIPs/blob/8e56fc593ece5c74f18b8eb68c3f9dcedf2396a7/DIPs/DIP1033.md
>>>
>>> The review period will end at 11:59 PM ET on December 4, 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.
>>>
>>
>> So, the thing that makes me nervous about this DIP, is that it may
>> substantially proliferate allocated closures.
>> I would want to have high confidence that people exclusively use `scope`
>> delegates, such that the closure can (will?/must?) be stack allocated.
>>
>> In my experience, in the rare instance that I want to use a lazy
>> parameter in the sorts of ways that might be affected by this DIP, it's
>> usually in support of a fairly small optimisation, or a modest convenience
>> in the API.
>> Relative to that optimisation, if there's a risk of introducing a closure
>> allocation, that would vastly out-weight the advantage by my judgement, and
>> it's very easy for such allocations to go unnoticed. It's completely
>> invisible.
>>
>> I would appeal that this DIP be changed such that auto-delegates must be
>> `scope`, and non-scope delegates should require the user to specify a
>> non-scope delegate argument using typical delegate syntax, so that you can
>> plainly see it.
>> Without requiring `scope` delegates, the risk of hidden allocations is
>> extremely high, and it's almost certainly NOT what anybody would ever want
>> from a lazy argument, which is virtually always an INPUT argument, and
>> shouldn't be retained past the life of the call.
>>
>
> Another question that comes to mind, where the dip shows:
>
> int delegate() dg = () { return 3; };
>
> becomes:
>
> int delegate() dg = () => 3;
>
> become simply:
>
> int delegate() dg = 3;
>
>
> <https://github.com/dlang/DIPs/blob/8e56fc593ece5c74f18b8eb68c3f9dcedf2396a7/DIPs/DIP1033.md#prior-work>
> This isn't an example of passing a lazy argument to a function that
> receives a delegate; this demonstrates initialising a delegate variable
> declaration. That seems off-topic to me, but it raises the question, does
> this now work for delegates that receive parameters:
>
>     int delegate(int x) dg = x + 10;
>
> ??
> Are the parameters in scope for the expression to the right of the `=`?
>
> This question doesn't really apply to the DIP, because a lazy argument delegate must necessarily have zero parameters... but the example shown here in the DIP raises questions along that associated path.
>

...  I think both of those posts should have been in the feedback thread?

On Friday, 20 November 2020 at 08:06:07 UTC, Manu wrote:
> So, the thing that makes me nervous about this DIP, is that it may
> substantially proliferate allocated closures.
> I would want to have high confidence that people exclusively use `scope`
> delegates, such that the closure can (will?/must?) be stack allocated.

I have similar concerns. At least `lazy` doesn't cause an delegate allocation, even on -O0; be a shame to give that up.

On 20/11/2020 9:06 PM, Manu wrote:
> So, the thing that makes me nervous about this DIP, is that it may substantially proliferate allocated closures.
> I would want to have high confidence that people exclusively use `scope` delegates, such that the closure can (will?/must?) be stack allocated.

One way to do this would be to add a new compiler check: @localnogc (can call methods that are not @nogc, but cannot do any direct calls to GC like new (apart from exceptions)).

It is something that has been on my mind for a while now. But that wouldn't help for forcing the caller You'd still need to use scope on the parameter.

On 11/20/2020 12:18 AM, Manu wrote:
> [...]

I'd appreciate it if you would delete irrelevant quoting en masse of the entire message you're replying to, when it has nothing to do with your message. It's just noisy. Thanks!

Or you could do like I do, and just replace it with [...]

On 11/20/2020 12:18 AM, Manu wrote:
> Another question that comes to mind, where the dip shows:
> 
> int  delegate() dg = () {return  3; };
> 
> becomes:
> 
> int  delegate() dg = ()=>  3;
> 
> become simply:
> 
> int  delegate() dg =3;
> 
> 
>     <https://github.com/dlang/DIPs/blob/8e56fc593ece5c74f18b8eb68c3f9dcedf2396a7/DIPs/DIP1033.md#prior-work>
> 
> This isn't an example of passing a lazy argument to a function that receives a delegate; this demonstrates initialising a delegate variable declaration. That seems off-topic to me, but it raises the question, does this now work for delegates that receive parameters:
> 
>      int delegate(int x) dg = x + 10;
> 
> ??
> Are the parameters in scope for the expression to the right of the `=`?

No. Initializers are semantically analyzed before the initialized, hence the parameter x will be unknown. You'll have to declare it as:

    int delegate(int) dg = (int x) { return x + 10; };

On 11/20/2020 12:06 AM, Manu wrote:
> So, the thing that makes me nervous about this DIP, is that it may substantially proliferate allocated closures.
> I would want to have high confidence that people exclusively use `scope` delegates, such that the closure can (will?/must?) be stack allocated.
> 
> In my experience, in the rare instance that I want to use a lazy parameter in the sorts of ways that might be affected by this DIP, it's usually in support of a fairly small optimisation, or a modest convenience in the API.
> Relative to that optimisation, if there's a risk of introducing a closure allocation, that would vastly out-weight the advantage by my judgement, and it's very easy for such allocations to go unnoticed. It's completely invisible.
> 
> I would appeal that this DIP be changed such that auto-delegates must be `scope`, and non-scope delegates should require the user to specify a non-scope delegate argument using typical delegate syntax, so that you can plainly see it.
> Without requiring `scope` delegates, the risk of hidden allocations is extremely high, and it's almost certainly NOT what anybody would ever want from a lazy argument, which is virtually always an INPUT argument, and shouldn't be retained past the life of the call.

Hmm, this is a good point I never thought of. Well put!