ImportC and nothrow/@nogc?

[Walter Bright]

On 8/21/2024 10:27 PM, Manu wrote:
> 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've used it in hybrid C and D programs. It also comes about when one is 
"transitioning" C code to D code. Enabling use of D code in a C project without 
needing a D main() entry point is a nice plus.


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

Some years back, I got into a terrific disagreement with everyone else in the D 
community when I wanted C declarations to default to @trusted :-/


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

I'm reluctant to add more flags as every one of them is a hack, and an admission 
of language design failure. A compiler should "just work".


> 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

Yes, it does. setjmp()/longjmp() are in the C Standard 7.13.

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

I understand your concern. Perhaps we can approach it from a different direction 
- why do you need the code to be nothrow and @nogc?

I don't know if this would work for you, but you could also try -betterC, which 
is implicitly @nogc.

For reference, the following enables calling a throwing function from a nothrow 
function:

```
nothrow int horse(int x, int y)
{
     try
     {
         battery();
     }
     catch (Exception e)
     {
     }
     return x = y + 3;
}

int battery()
{
     throw new Exception("hello");
}
```