Discussion Thread: DIP 1033--Implicit Conversion of Expressions to Delegates--Final Review

[Timon Gehr]

On 22.11.20 10:18, Walter Bright wrote:
> 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!

There's plenty of tools to prevent implicit allocations and if the 
delegate is dropped after the function call, it will be `scope` anyway. 
The benefit of allowing a closure allocation is that it becomes possible 
to implement actual lazy evaluation.