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;

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.