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

[Manu]

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>