Attribute transference from callbacks?

[Timon Gehr]

On 12/8/24 06:54, Manu wrote:
> Here's the stupidest idea ever: expand inout to take an argument...
> 
> void parseThings(string s, void delegate(Thing) inout(nothrow) 
> inout(@nogc) sink) inout(nothrow) inout(@nogc)
> {
>    //...
>    sink(Thing());
>    //...
> }
> ...

Issue with this is you will still not know which `inout`s match up. This 
is already an issue with the existing `inout`, which just arbitrarily 
selects a convention. In particular, it does not really work with 
higher-order functions the way you'd need it to here.

> Surely people have had better ideas? But you get the point, and this is 
> basically essential to make the 'sink' pattern work at all in D.
> 
> No, no templates; it's not right to generate multiple copies of identical functions just because something it CALLS would transfer an attribute. The function itself is identical no matter the state of any attribute transference, and so this isn't a template problem; it's a pattern matching problem.

Well, it can be seen as a homogeneous vs heterogeneous compilation 
problem. The attributes can still act a bit like template parameters, 
but only one instance must be created that works for all of them. It's 
sometimes called parametric polymorphism.