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

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

On Fri, Nov 20, 2020 at 6:18 PM Manu <turkeyman at gmail.com> wrote:

> On Fri, Nov 20, 2020 at 6:06 PM Manu <turkeyman at gmail.com> wrote:
>> 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.
> Another question that comes to mind, where the dip shows:
> int delegate() dg = () { return 3; };
> becomes:
> int delegate() dg = () => 3;
> become simply:
> int delegate() dg = 3;
> <https://github.com/dlang/DIPs/blob/8e56fc593ece5c74f18b8eb68c3f9dcedf2396a7/DIPs/DIP1033.md#prior-work>
> This isn't an example of passing a lazy argument to a function that
> receives a delegate; this demonstrates initialising a delegate variable
> declaration. That seems off-topic to me, but it raises the question, does
> this now work for delegates that receive parameters:
>     int delegate(int x) dg = x + 10;
> ??
> Are the parameters in scope for the expression to the right of the `=`?
> This question doesn't really apply to the DIP, because a lazy argument
> delegate must necessarily have zero parameters... but the example shown
> here in the DIP raises questions along that associated path.

...  I think both of those posts should have been in the feedback thread?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20201120/28b962b2/attachment-0001.htm>

More information about the Digitalmars-d mailing list