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

[Manu]

On Mon, Nov 23, 2020 at 7:46 AM Timon Gehr via Digitalmars-d <
digitalmars-d at puremagic.com> wrote:

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

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

Please consider a conservative approach, and lift the restriction in the
future if there's demonstrated advantage.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20201123/dffcd447/attachment.htm>