ImportC and nothrow/@nogc?

[Richard (Rikki) Andrew Cattermole]

On 29/08/2024 1:41 AM, Manu wrote:
>      > And if someone does a binary-back-door... who cares? That's
>     called a BUG.
>      > They're playing with fire already! C doesn't have any such type
>     safety, and they
>      > shouldn't expect it to.
>      > They know what they did; they did it intentionally, surely knew
>     what the risk
>      > factors were, and they are naturally expected to not write such
>     bugs into their
>      > program.
> 
>     The author of the C code likely has no idea that the caller from D
>     exists let
>     alone that it would require that the C code not call any D functions.
> 
> 
> The author of the library expects you to use the library via the API 
> they provide... their API is C code; if C code is nothrow @nogc, then 
> the callback you provide is necessarily nothrow and @nogc also.
> I really can't see the fuss here...

I've just had a thought, an old idea of mine is called contract 
invalidation. What it does is if you have an argument for say a function 
pointer that doesn't have an attribute, the attribute comes off the 
called function.

Useful for opApply, but it might be perfect here too.

ImportC can default to nothrow, @nogc, @system.

If you pass in a callback that throws or uses GC, then so does the function.

Its @system, so compiler isn't making any guarantees in terms of safety 
anyway.

I know Timon wants something more powerful than this, but... it could 
work here.