<div dir="ltr"><div dir="ltr">On Mon, Nov 23, 2020 at 7:46 AM Timon Gehr 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">On 22.11.20 10:18, Walter Bright wrote:<br>
> On 11/20/2020 12:06 AM, Manu wrote:<br>
>> So, the thing that makes me nervous about this DIP, is that it may <br>
>> substantially proliferate allocated closures.<br>
>> I would want to have high confidence that people exclusively use <br>
>> `scope` delegates, such that the closure can (will?/must?) be stack <br>
>> allocated.<br>
>><br>
>> In my experience, in the rare instance that I want to use a lazy <br>
>> parameter in the sorts of ways that might be affected by this DIP, <br>
>> it's usually in support of a fairly small optimisation, or a modest <br>
>> convenience in the API.<br>
>> Relative to that optimisation, if there's a risk of introducing a <br>
>> closure allocation, that would vastly out-weight the advantage by my <br>
>> judgement, and it's very easy for such allocations to go unnoticed. <br>
>> It's completely invisible.<br>
>><br>
>> I would appeal that this DIP be changed such that auto-delegates must <br>
>> be `scope`, and non-scope delegates should require the user to specify <br>
>> a non-scope delegate argument using typical delegate syntax, so that <br>
>> you can plainly see it.<br>
>> Without requiring `scope` delegates, the risk of hidden allocations is <br>
>> extremely high, and it's almost certainly NOT what anybody would ever <br>
>> want from a lazy argument, which is virtually always an INPUT <br>
>> argument, and shouldn't be retained past the life of the call.<br>
> <br>
> Hmm, this is a good point I never thought of. Well put!<br>
<br>
There's plenty of tools to prevent implicit allocations and if the <br>
delegate is dropped after the function call, it will be `scope` anyway. <br>
The benefit of allowing a closure allocation is that it becomes possible <br>
to implement actual lazy evaluation.<br></blockquote><div><br></div><div>You can just write `() => expr` in that case, then the allocation is visible. I think the risk of hidden allocated closures is substantial and shouldn't be taken lightly, and I don't see evidence that deferred lazy functions is a popular enough pattern to justify accepting this risk.</div><div>This is a restriction that can be trivially lifted in the future if the pattern you describe is prolific and my suggestion is proven to be cumbersome, but it's virtually impossible to add the restriction in the future once the cat is already out of the bag.</div><div>I am _deeply_ concerned by a core language syntax that may invisibly result in random allocations at any function callsite. It's also the sort of thing that would be extremely off-putting to tech-directors doing technology/language assessments in my industry; it's at the level where it could tip someone's judgement.</div><div><br></div><div>Please consider a conservative approach, and lift the restriction in the future if there's demonstrated advantage.</div></div></div>