ImportC and nothrow/@nogc?

[Jonathan M Davis]

On Monday, August 26, 2024 11:54:06 PM MDT Manu via Digitalmars-d wrote:
> We're not talking about @trusted, we're talking about nothrow and @nogc...
> the community voices that have presented here so far seem to agree; I don't
> think you're being pressured by competing opinions.
> I *suggest* you make the change, OR consider adding a command line arg to
> override it; and optionally make that argument apply to an isolated source
> tree if you're feeling particularly conservative. (I wouldn't do that, but
> the more conservative might consider it)
> The situation as it stands is a literal tragedy... you put a lot of work
> into this.
>
> Realistically speaking; C calls are not going to throw or gcalloc. You can
> contrive a situation, but you have to go miles out of your way to arrange
> that.
> Any C library that operates via callbacks will have an API that also has
> those attributes attached; in a nothrow @nogc C interface, the user can't
> provide a callback that can throw or GC. The only risk vector is as you
> described earlier; *mixed use* of the API and using a binary back-door.
> The whole point of ImportC, is to use the API.
>
> 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.

Yeah. We already have the ability to declare C bindings without importC. The
normal use case for importC is to "import" actual C code without having to
write and maintain a bunch of bindings, and realistically, that code is
going to be implemented as nothrow and @nogc, because normal C code is
nothrow and @nogc. Yes, it's _technically_ possible to have C functions
using D features and import them with importC, but who is actually going to
do that in practice?

Not treating importC functions as nothrow and @nogc is hurting the intended
use case for importC without really enabling much. It seems to me that if
anyone really wants to have C code using the GC or throwing exceptions, they
can just use C bindings like they've been able to do for many years, whereas
having importC assume nothrow and @nogc will make the feature work much
better for the problem that it's actually trying to solve.

If need be, we can put it as a caveat in the importC documentation that
extern(C) functions implemented with D which should not be treated as
nothrow or @nogc cannot be used with importC, but I question that anyone
will ever feel constrained by that. The current situation is a pessimization
which makes importC worse for its actual use case for fear of causing
problems for a use case which might not even ever exist in practice.

It seems to me that it would be much better to just assume nothrow and @nogc
and document that behavior, allowing the few (if any) who want something
else to just write their own C bindings. As it is, they're probably writing
their own extern(C) functions anyway rather than looking to import C
headers, because their code is D rather than C.

- Jonathan M Davis