On Wed, 28 Aug 2024 at 23:52, Richard (Rikki) Andrew Cattermole via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
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.

That's an interesting idea in other contexts; but I don't see it's relevant here. This is not an engineering problem that needs to be solved.