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

Manu turkeyman at gmail.com
Fri Nov 20 08:06:07 UTC 2020


On Fri, Nov 20, 2020 at 5:30 PM Mike Parker via Digitalmars-d <
digitalmars-d at puremagic.com> wrote:

> This is the discussion thread for the Final Review of DIP 1033,
> "Implicit Conversion of Expressions to Delegates":
>
>
> https://github.com/dlang/DIPs/blob/8e56fc593ece5c74f18b8eb68c3f9dcedf2396a7/DIPs/DIP1033.md
>
> The review period will end at 11:59 PM ET on December 4, or when
> I make a post declaring it complete. Discussion in this thread
> may continue beyond that point.
>
> Here in the discussion thread, you are free to discuss anything
> and everything related to the DIP. Express your support or
> opposition, debate alternatives, argue the merits, etc.
>
> However, if you have any specific feedback on how to improve the
> proposal itself, then please post it in the feedback thread. The
> feedback thread will be the source for the review summary I write
> at the end of this review round. I will post a link to that
> thread immediately following this post. Just be sure to read and
> understand the Reviewer Guidelines before posting there:
>
> https://github.com/dlang/DIPs/blob/master/docs/guidelines-reviewers.md
>
> And my blog post on the difference between the Discussion and
> Feedback threads:
>
> https://dlang.org/blog/2020/01/26/dip-reviews-discussion-vs-feedback/
>
> Please stay on topic here. I will delete posts that are
> completely off-topic.
>

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20201120/7465e1f7/attachment.htm>


More information about the Digitalmars-d mailing list