On Thu, 22 Aug 2024 at 05:51, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

On 8/20/2024 2:12 AM, Manu wrote:
> Exactly... these points are my precise assumption going in here.
> Also, considering the possibility that D code is called from C code via a
> function pointer; you have to wonder how the C code received a function pointer
> in the first place? If the C code is nothrow @nogc, then it would be impossible
> to supply a function pointer that was not also nothrow @nogc to the C code in
> the first place.

```
// D file:
extern (C) void daFunc() { throw new Exception(); }
```

```
// C file:
extern void daFunc();

void hahahahaha() { daFunc(); }
```

No function pointers required. The D <=> C interoperability goes both ways.

That's not a C program, that's a D program with some C code sprinkled in.

But right... a mixture of extern(C) in D code, and also ImportC used in conjunction, where the ImportC code makes explicit use of symbols that it expects to find externally...

Feels unlikely, pretty contrived; why would you be using extern(C) if you are also using ImportC? They're kinda mutually exclusive for my interest. I wouldn't use ImportC if I was satisfied to write extern(C) bindings.

I mean, being overly cautious like this is not in the spirit of using C code at all! C code will _always_ introduce these sorts of risks 100% without question. If you're stressed about this, while also having no agency to control your environment or test your programs validity, you kinda have no business linking to C code in the first place.

But all that as it is, so... we add a compiler flag to control whether these 2 attributes are applied to ImportC declarations or not?

The current situation is not reasonable. You've done all this work and made all this hype, the first time I want to make use of it, it turns out it's not actually usable by the exact sort of code that seems the most likely to want to use the feature in the first place!

C doesn't throw or GC, period. Of course I can contort a C environment to do whatever I want; but the argument that C can throw or can GC alloc implies that the C code is not actually C code... it is infact actually just a small piece of connective tissue in some non-C project.

A C library that is a self-contained package does not call C++ code or D code. We need a way to assert this case. I think a compile option which asserts this case seems fine.

Maybe apply the arg to a directory; in the event there are multiple C libraries being included in the project, it only applies to C code under that path, like some self-contained libraries?