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

[Dennis]

On Tuesday, 28 July 2020 at 22:30:22 UTC, Walter Bright wrote:
>> What if I call toString with a lambda that is pure, will it 
>> force toString to be pure?
>
> No, not under this DIP.

It was not a question directed at you, but more like a rhetorical 
question about the alternative proposal that I answered the next 
sentence. This figure of speech translates poorly on text 
evidently, I'll try to avoid it next time.

> I suspect you're misuderstanding what the DIP proposes? The 
> proposal does not remove any attributes from toString. It only 
> adds the attributes from toString to the lambda.

I think I understand exactly what the DIP proposes and why, and I 
am in favor of making attributes in function/delegate parameters 
more ergonomic and going towards deprecating the `lazy` keyword.

However, there's another problem related to delegate parameters 
that we are trying to solve: the lack of "inout attributes". 
Maybe you don't relate to this problem, or you think this is 
material for another DIP. I think this is important though, so 
I'll elaborate a bit more.

Let's take the example of using opApply on a binary tree from the 
Dlang tour:
https://tour.dlang.org/tour/en/gems/opdispatch-opapply

Imagine someone writes a library with that tree data structure:
```
module binarytree;
class Tree {
     Tree lhs;
     Tree rhs;
     int opApply(int delegate(Tree) dg) {
         if (lhs && lhs.opApply(dg)) return 1;
         if (dg(this)) return 1;
         if (rhs && rhs.opApply(dg)) return 1;
         return 0;
     }
}
```

Great! But now one the library users opens an issue. That user 
wrote this code:
```
import binarytree;
int nodeCount(Tree tree) @safe @nogc pure nothrow {
     int result = 0;
     foreach(node; tree)
         result++;
     return result;
}
```

The user says "I get all these errors that I cannot call 
binarytree.Tree.opApply because it's impure, @system, non- at nogc, 
and it may throw"

The library author says "I got you. I will mark the opApply 
function @safe @nogc pure nothrow". Now that user is happy, but a 
different user opens an issue. The second user wrote this code:
```
import binarytree, std.stdio;
void main() {
     Tree tree = new Tree();
     foreach(node; tree)
         writeln(node);
}
```

The second user says "I get this weird error that I cannot pass 
argument __foreachbody1 of type int delegate(Tree node) @system 
to parameter int delegate(Tree) pure nothrow @nogc @safe dg" The 
library author replies "well, I could remove those attributes 
from opApply, but that breaks the code of the first user again".

How would you solve this if you were the library author?
To be clear: this IS a question directed at you, Walter ;)

However, the alternative proposal to DIP 1032 would solve this, 
making both users and the library author happy. On top of that, 
it would solve the issues described in DIP 1032, killing two 
birds with one stone. The current proposal in DIP 1032 is only 
killing one bird with one stone.