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

[Timon Gehr]

On 23.11.20 09:01, Manu wrote:
> ...
>      >> 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.
> 
> 
> 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.

I am not sure this is even officially supported right now. Taking the 
address of a lazy parameter is not @safe. (This might be an oversight, 
though I'm pretty sure the documentation used to state that lazy implies 
scope.)

> 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.
> I am _deeply_ concerned by a core language syntax that may invisibly 
> result in random allocations at any function callsite.

It really does not matter much whether the allocation is at the callsite 
or at the beginning of the function itself. If it's at the call site, at 
least you can tell from the function signature...

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

We have @nogc. What's the point of even supporting @nogc if this kind of 
rhetoric continues anyway? I'd rather have a language that is useful 
instead of one that appeals to people with bad decision making.

> Please consider a conservative approach, and lift the restriction in the 
> future if there's demonstrated advantage.

It's not up to me.