ImportC and nothrow/@nogc?

[Manu]

On Wed, 28 Aug 2024 at 23:52, Richard (Rikki) Andrew Cattermole via
Digitalmars-d <digitalmars-d at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20240829/0a69d145/attachment.htm>