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

[Manu]

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