<div dir="ltr"><div dir="ltr">On Fri, Nov 20, 2020 at 5:30 PM Mike Parker via Digitalmars-d <<a href="mailto:digitalmars-d@puremagic.com">digitalmars-d@puremagic.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">This is the discussion thread for the Final Review of DIP 1033, <br>
"Implicit Conversion of Expressions to Delegates":<br>
<br>
<a href="https://github.com/dlang/DIPs/blob/8e56fc593ece5c74f18b8eb68c3f9dcedf2396a7/DIPs/DIP1033.md" rel="noreferrer" target="_blank">https://github.com/dlang/DIPs/blob/8e56fc593ece5c74f18b8eb68c3f9dcedf2396a7/DIPs/DIP1033.md</a><br>
<br>
The review period will end at 11:59 PM ET on December 4, or when <br>
I make a post declaring it complete. Discussion in this thread <br>
may continue beyond that point.<br>
<br>
Here in the discussion thread, you are free to discuss anything <br>
and everything related to the DIP. Express your support or <br>
opposition, debate alternatives, argue the merits, etc.<br>
<br>
However, if you have any specific feedback on how to improve the <br>
proposal itself, then please post it in the feedback thread. The <br>
feedback thread will be the source for the review summary I write <br>
at the end of this review round. I will post a link to that <br>
thread immediately following this post. Just be sure to read and <br>
understand the Reviewer Guidelines before posting there:<br>
<br>
<a href="https://github.com/dlang/DIPs/blob/master/docs/guidelines-reviewers.md" rel="noreferrer" target="_blank">https://github.com/dlang/DIPs/blob/master/docs/guidelines-reviewers.md</a><br>
<br>
And my blog post on the difference between the Discussion and <br>
Feedback threads:<br>
<br>
<a href="https://dlang.org/blog/2020/01/26/dip-reviews-discussion-vs-feedback/" rel="noreferrer" target="_blank">https://dlang.org/blog/2020/01/26/dip-reviews-discussion-vs-feedback/</a><br>
<br>
Please stay on topic here. I will delete posts that are <br>
completely off-topic.<br></blockquote><div><br></div><div>So, the thing that makes me nervous about this DIP, is that it may substantially proliferate allocated closures.</div><div>I would want to have high confidence that people exclusively use `scope` delegates, such that the closure can (will?/must?) be stack allocated.</div><div><br></div><div>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.</div><div>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.</div><div><br></div><div>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.</div><div>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.</div></div></div>