Discussion Thread: DIP 1032--Function pointers and Delegate Parameters...--Community Review Round 1

[Dukc]

Answering the DIP authors message at the feedback theard

On Wednesday, 20 May 2020 at 05:58:23 UTC, Walter Bright wrote:
> On 4/3/2020 3:23 PM, Dukc wrote:
>> I completely disagree with the notion that delegates with 
>> conventional syntax should inherit the attributes of the 
>> function. First, the code breakage is going to be high 
>> relative to the benefit.
>
> That would only be true if the function never calls the 
> delegate (i.e. it only stores the delegate elsewhere), which 
> does happen but is not the usual use.

True, but considering for long the feature has been around, I 
can't see this reducing the damage enough. If we were in alpha 
state doing D3, I wouldn't be worried. But for a stable language 
it's a desperate move to rely on assumptions like that. The 
additional attribute soup that would result from Jonathan Marlers 
proposal at the feedback theard may be bad, but less so than the 
breakage you're proposing.

And while I am at it, remember that the Marlers proposal will 
still in a way reduce attribute soup, because

```
@safe pure nothrow fun(@called void delegate(int) a)
```

is better than


```
@safe pure nothrow fun(@safe pure nothrow void delegate(int) a)
```
(and does not require `a` to always be `@safe pure nothrow`. See 
later why.)

>
>
>> Second, we are talking about adding a special case to the 
>> language semantics, that is likely going to be hard to 
>> understand and thus, to learn and remember.
>
> On the contrary, it will likely not even be noticed. For 
> example, it only makes sense that a pure function would need 
> its delegate parameters to also be pure so it can call them. 
> It's annoying to have to specify `pure` twice.
>

I was talking about the reverse case. Someone wants to just store 
the delegate somewhere. We would have to explain why he/she needs 
to alias the function pointer or delegate separately. After all, 
normally

```
alias Y = X;
void fun(Y a);
```

behaves the same as

```
void fun(X a);
```

. Your proposal would add a special case to that rule.

>
>> If this proposal is changed to only propose this change to 
>> `lazy` parameters, it might just be worth considering. `lazy` 
>> is already kind of "special" in it's behaviour so I could see 
>> the special casing pshycologically easier to accept there. But 
>> even there I'm sceptical.
>
> The idea is to get rid of the special cases of lazy.
>

I quess that moves to the territory of your other dip, that wants 
to make every possible parameter `lazy`. No need to discuss that 
here.

>
>> What I'm saying next will be off the scope of the DIP, but I 
>> say it because of the possibility that the DIP is 
>> unintentionally trying to solve the wrong problem. The biggest 
>> problem with delegates in attributes is not that they don't 
>> infer the attributes from the called function -vice versa! In 
>> the ideal world, the called function would infer it's 
>> attributes from the delegate, not unlike how `inout` function 
>> infers it's return value constness from constness of the 
>> `inout` parameter.
>
> Inferring function attributes from the delegate argument is 
> impractical. For example, many delegates are trivial lambda 
> functions, often inferred as pure. But the functions that call 
> those delegates can rarely be pure. In effect, the function 
> would have to be compilable with the *tightest* combination of 
> attributes every time.

No. The idea is not to infer new attributes from the delegate 
parameter. The idea is to infer which attributes the function CAN 
RETAIN when it calls the delegate. For example:

```
@safe pure nothrow fun(@called void delegate(int) a)
```

If this was called with a being `@safe pure nothrow @nogc` 
delegate, the function call would be `@safe pure nothrow`, but 
not `@nogc`. On the other hand, if `a` is `@system nothrow`, the 
function call will be inferred as `@system nothrow`.

So only those attributes the function can comply with are 
inferred, not others. The above example function could still use 
the garbage collector.