On 8/26/2024 11:12 AM, Timon Gehr wrote:
> Marking every C function `@trusted` would not solve his problem. What would solve his problem is if ImportC supported C extensions that let you mark groups of declarations using D attributes. Then you can put those in the C files that you import.

People are very reluctant to modify their C files, as they usually come from outside their organization. I've done a lot of work on ImportC to get it to work with unmodified C code.

Note that Manu rejected my suggestion to use ImportC to generate .di files of the function prototypes, and then edit in the attributes. This is equivalent to your suggestion.

On 8/26/2024 11:32 PM, Manu wrote:
> Can we direct this thread back towards nothrow and @nogc?
> This wasn't actually a conversation about @trusted...

They are closely related enough that the same issues apply.

On 8/26/2024 10:54 PM, Manu wrote:
> The whole point of ImportC, is to use the API.

Initially, yes. But the mission creep has already happened, and why not?

> 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.

On 8/26/2024 11:29 PM, Jonathan M Davis wrote:
> 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?

Anyone adding D functions to a C code base. This is the "gradual migration" strategy. I've used it, and C/C++ users do it a lot between C and C++.



> 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.

You're right, until someone does it and it breaks in some bizarre way.

You and Manu are right, this is a problem. There's got to be a better, correct solution.

On 8/26/2024 10:26 AM, Steven Schveighoffer wrote:
> Does this actually interact with D code properly? Like, does this work?

Nope. D doesn't emit EH stack frames for nothrow functions.


> I don't think you understand the problem here.
> 
> `printf` doesn't use the GC. It doesn't throw. This is not conjecture or philosophy, it objectively, explicitly does not do this.

I know everything there is to know about printf. I've implemented a Standard compliant one :-)

I've also proposed an exemption to make printf usable from @safe code.


> This must be fixed. There is no other option. If this is not fixed, you cannot use importC to actually import C.

I remember when you were adamantly against C code defaulting to @trusted. Assuming nothrow and @nogc is in the same category.

I agree this is a problem.

On Wed, 28 Aug 2024 at 08:12, Walter Bright via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On 8/26/2024 10:54 PM, Manu wrote:
> > The whole point of ImportC, is to use the API.
>
> Initially, yes. But the mission creep has already happened, and why not?
>

Where has it happened? The mission isn't even off the ground. I thought I'd
have a go, and it's a complete non-starter.
So no, I really just want to use the C API; it's called ImportC; surely
that's _literally the point_.


> 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...

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.