Attribute transference from callbacks?

[Zach Tollen]

On Sunday, 15 December 2024 at 07:04:54 UTC, Richard (Rikki) 
Andrew Cattermole wrote:
> ``nothrow`` is a very bad example to give here.
>
> In fact, it needs an entirely separate mechanism from the 
> others.
>
> It isn't boolean, and has codegen changes associated with it.

That's fair. I don't know if delegates work with exception 
handlers in a way that would permit this mechanism. Like, if a 
function is otherwise `nothrow`, but is called with a delegate 
parameter which throws, can the function be compiled to allow the 
throwing delegate to bypass the function it is called within and 
have the delegate throw straight to the calling function instead? 
Probably not, but I don't know enough about how modern exception 
handlers are programmed to know for sure.

> Also in your example, the delegate could be marked as throwing 
> and it would work today.
>
> ``nothrow`` is already scope aware.

Under the current system, the following is an error:
```d
// Error: function `g` may throw but is marked as `nothrow`
void g(void delegate() sink) nothrow {
     sink();
}
```
Under the new system (apart from the mechanism and codegen issues 
you raised), the above would be permitted... only if you called 
it with a throwing delegate would it be classified as throwing, 
and at the call site, but not in the function itself. This is 
much cleaner. I believe that it is primarily within this context 
that the new attribute `@noimply` would be occasionally useful, 
as a way to say that even if you call the `nothrow` function with 
a *throwable* delegate, the call can *still* be treated as 
`nothrow`, because `@noimply(throw)` statically guarantees that 
any incoming throw will be neutralized.

I'm pretty sure the purpose of `@noimply` would only become 
apparent if the new default were already adopted.