On Sunday, 8 December 2024 at 05:54:40 UTC, Manu wrote:
> I've been trying out an API strategy to use sink functions a
> lot more to hoist the item allocation/management logic to the
> user and out from the work routines. This idea has received a
> lot of attention, and I heard a lot of people saying this was a
> planned direction to move in phobos and friends.
>
> ```d
> void parseThings(string s, void delegate(Thing) sink)
> {
>   //...
>   sink(Thing());
>   //...
> }
> ```
>
> We have a serious problem though; a function that receives a
> sink function
> must transfer the attributes from the sink function to itself,
> and we have
> no language to do that...
> What are the leading strategies that have been discussed to
> date? Is there
> a general 'plan'?

I've proposed something like the following in the past, but I
don't know how much appetite there is for it:

```d
// assuming Thing() is @nogc nothrow @safe, but not pure
void parseThings(string s, @called void delegate(Thing) sink)
@nogc nothrow @safe
{
    sink(Thing());
}
```

Essentially, how this would work is that the compiler would
consider all code inside the function except the call of the
delegate to be attributed with the provided attributes. However,
the delegate call will *always work*. All that will happen is
that the call to `parseThings` will have any restrictions removed
that aren't on the delegate.

So e.g. a delegate of `@nogc pure` but not `nothrow` or `@safe`
will mean `parseThings(dg)` will be treated like it's `@nogc`.

Because the list of attributes `@nogc nothrow @safe` is
logic-anded with `@nogc pure`.

No recompile is necessary.

If you want to insist that some attribute must be on the
delegate, you can add the attribute to the delegate parameter. So
if I wanted to insist that you must pass in at least a `@safe`
delegate:

```d
void parseThings(string s, @called void delegate(Thing) @safe
sink) { ... }
```

As far as I know, there is no plan to make something like this
happen.

-Steve