Feedback Thread: DIP 1041--Attributes for Higher-Order Functions--Community Review Round 1

[Timon Gehr]

On 12.04.21 11:38, Mike Parker wrote:
> ## Feedback Thread
> 
> ...
> 
> You can find DIP 1041 here:
> 
> https://github.com/dlang/DIPs/blob/11fcb0f79ce7ec209fb2a302d1371722d0c8ad82/DIPs/DIP1041.md 
> ...

Unfortunately, it is not written too well: The reader gets flooded with 
details way before being told what the problem actually is or how the 
proposal addresses it.

As far as I can tell, this is trying to introduce attribute polymorphism 
without actually adding polymorphism, much like `inout` attempted and 
ultimately failed to do. I am very skeptical. It's taking a simple 
problem with a simple solution and addressing it using an overengineered 
non-orthogonal mess in the hopes of not having to add additional syntax.

To add insult to injury, the first example that's shown in the DIP as 
motivation abuses an existing type system hole. `toString` is `const`, 
`sink` is `const`, the only reference to result accessible to `toString` 
is in the context of `sink`, but somehow `result` is mutated anyway. 
Unsoundness should be fixed, not embraced!

Finally, there's this concern: The DIP assumes that the only reasonable 
way to manipulate delegates in higher-order functions involves calling 
them, but this is not accurate. E.g.:

---
auto compose(A,B,C)(C delegate(B) f, B delegate(A) g)pure{
     return a=>f(g(a));
}
---

With the proposed changes, composing impure functions suddenly becomes 
an impure operation as soon as you abstract it into a higher-order 
function. This is pure nonsense. If you have a `pure` expression and 
abstract it into a `pure` function, it should not become less `pure` in 
the process!


E.g., consider this:

---
auto compose2(A,B,C)(C delegate(B) f, B delegate(A) g)pure{
     return compose(f,g);
}
---

With the changes proposed in the DIP, this does not even compile, 
breaking abstraction/perfect forwarding.