I just tried using ImportC for the first time ever, but I was surprised
when I immediately received a sea of errors calling the C symbols from
`nothrow @nogc` functions.
My entire program is `nothrow @nogc`... I assumed ImportC would be
supremely suitable in this context, but apparently not...

Is there something I've missed? Is there a plan for this?
I found just one single very short forum thread...

This is classic D experience; so much work has been done on this, and then the moment I try and use something I encounter a showstopping oversight >_<

On Sunday, 18 August 2024 at 04:43:34 UTC, Manu wrote:
> I just tried using ImportC for the first time ever, but I was surprised
> when I immediately received a sea of errors calling the C symbols from
> `nothrow @nogc` functions.
> My entire program is `nothrow @nogc`... I assumed ImportC would be
> supremely suitable in this context, but apparently not...
>
> Is there something I've missed? Is there a plan for this?
> I found just one single very short forum thread...
>
> This is classic D experience; so much work has been done on this, and then the moment I try and use something I encounter a showstopping oversight >_<

Well, C may call C++ which may throw. It is very unlikely to call the GC however.

I don't think it would be hard to add a switch that "`extern(C)` functions being called from import C are `@nogc`".

On Sunday, 18 August 2024 at 09:42:16 UTC, Nicholas Wilson wrote:
> On Sunday, 18 August 2024 at 04:43:34 UTC, Manu wrote:
>> I just tried using ImportC for the first time ever, but I was surprised
>> when I immediately received a sea of errors calling the C symbols from
>> `nothrow @nogc` functions.
>> My entire program is `nothrow @nogc`... I assumed ImportC would be
>> supremely suitable in this context, but apparently not...
>>
>> Is there something I've missed? Is there a plan for this?
>> I found just one single very short forum thread...
>>
>> This is classic D experience; so much work has been done on this, and then the moment I try and use something I encounter a showstopping oversight >_<
>
> Well, C may call C++ which may throw. It is very unlikely to call the GC however.
>
> I don't think it would be hard to add a switch that "`extern(C)` functions being called from import C are `@nogc`".

Here's what I'm thinking:

The C function interface has no notion of C++ exceptions (AFAIK it's following C specs, not C++), so C++ exceptions should not even be a consideration at that point. I do not think that throwing a C++ exception up a stack that contains extern(C) functions is even properly defined behavior on the C++ side. In other words, all ImportC declarations should be implicitly @nothrow.

Any usage of the D GC from a C interface could only come in two flavors: D code exported through a C interface or a C interface implemented in another language that uses the D GC through a library interface. I believe that both cases should be treated as if the use of the D GC is an implementation detail and an implicit @nogc is warranted.

On 20/08/2024 12:24 PM, Gregor Mückl wrote:
> On Sunday, 18 August 2024 at 09:42:16 UTC, Nicholas Wilson wrote:
>> On Sunday, 18 August 2024 at 04:43:34 UTC, Manu wrote:
>>> I just tried using ImportC for the first time ever, but I was surprised
>>> when I immediately received a sea of errors calling the C symbols from
>>> `nothrow @nogc` functions.
>>> My entire program is `nothrow @nogc`... I assumed ImportC would be
>>> supremely suitable in this context, but apparently not...
>>>
>>> Is there something I've missed? Is there a plan for this?
>>> I found just one single very short forum thread...
>>>
>>> This is classic D experience; so much work has been done on this, and then the moment I try and use something I encounter a showstopping oversight >_<
>>
>> Well, C may call C++ which may throw. It is very unlikely to call the GC however.
>>
>> I don't think it would be hard to add a switch that "`extern(C)` functions being called from import C are `@nogc`".
> 
> Here's what I'm thinking:
> 
> The C function interface has no notion of C++ exceptions (AFAIK it's following C specs, not C++), so C++ exceptions should not even be a consideration at that point. I do not think that throwing a C++ exception up a stack that contains extern(C) functions is even properly defined behavior on the C++ side. In other words, all ImportC declarations should be implicitly @nothrow.

Its defined for MSVC:

https://learn.microsoft.com/en-us/cpp/cpp/structured-exception-handling-c-cpp?view=msvc-170

"Structured exception handling (SEH) is a Microsoft extension to C and C++ to handle certain exceptional code situations, such as hardware faults, gracefully."

I'm pretty sure for other platforms it is also defined as part of unwinding, although I can't be bothered to hunt for the specification. It's not about C, it's about languages that are not C++ (consider JIT's for instance).

On Tue, 20 Aug 2024 at 10:26, Gregor Mückl via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On Sunday, 18 August 2024 at 09:42:16 UTC, Nicholas Wilson wrote:
> > On Sunday, 18 August 2024 at 04:43:34 UTC, Manu wrote:
> >> I just tried using ImportC for the first time ever, but I was
> >> surprised
> >> when I immediately received a sea of errors calling the C
> >> symbols from
> >> `nothrow @nogc` functions.
> >> My entire program is `nothrow @nogc`... I assumed ImportC
> >> would be
> >> supremely suitable in this context, but apparently not...
> >>
> >> Is there something I've missed? Is there a plan for this?
> >> I found just one single very short forum thread...
> >>
> >> This is classic D experience; so much work has been done on this, and then the moment I try and use something I encounter a showstopping oversight >_<
> >
> > Well, C may call C++ which may throw. It is very unlikely to call the GC however.
> >
> > I don't think it would be hard to add a switch that "`extern(C)` functions being called from import C are `@nogc`".
>
> Here's what I'm thinking:
>
> The C function interface has no notion of C++ exceptions (AFAIK it's following C specs, not C++), so C++ exceptions should not even be a consideration at that point. I do not think that throwing a C++ exception up a stack that contains extern(C) functions is even properly defined behavior on the C++ side. In other words, all ImportC declarations should be implicitly @nothrow.
>
> Any usage of the D GC from a C interface could only come in two flavors: D code exported through a C interface or a C interface implemented in another language that uses the D GC through a library interface. I believe that both cases should be treated as if the use of the D GC is an implementation detail and an implicit @nogc is warranted.
>

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.

SEH is not C or C++, it's a Microsoft thing with no standards to speak of. It seems irrelevant to this conversation to me.

On Tue, 20 Aug 2024 at 10:36, Richard (Rikki) Andrew Cattermole via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

>
> On 20/08/2024 12:24 PM, Gregor Mückl wrote:
> > On Sunday, 18 August 2024 at 09:42:16 UTC, Nicholas Wilson wrote:
> >> On Sunday, 18 August 2024 at 04:43:34 UTC, Manu wrote:
> >>> I just tried using ImportC for the first time ever, but I was surprised
> >>> when I immediately received a sea of errors calling the C symbols from
> >>> `nothrow @nogc` functions.
> >>> My entire program is `nothrow @nogc`... I assumed ImportC would be
> >>> supremely suitable in this context, but apparently not...
> >>>
> >>> Is there something I've missed? Is there a plan for this?
> >>> I found just one single very short forum thread...
> >>>
> >>> This is classic D experience; so much work has been done on this, and then the moment I try and use something I encounter a showstopping oversight >_<
> >>
> >> Well, C may call C++ which may throw. It is very unlikely to call the GC however.
> >>
> >> I don't think it would be hard to add a switch that "`extern(C)` functions being called from import C are `@nogc`".
> >
> > Here's what I'm thinking:
> >
> > The C function interface has no notion of C++ exceptions (AFAIK it's following C specs, not C++), so C++ exceptions should not even be a consideration at that point. I do not think that throwing a C++ exception up a stack that contains extern(C) functions is even properly defined behavior on the C++ side. In other words, all ImportC declarations should be implicitly @nothrow.
>
> Its defined for MSVC:
>
>
> https://learn.microsoft.com/en-us/cpp/cpp/structured-exception-handling-c-cpp?view=msvc-170
>
> "Structured exception handling (SEH) is a Microsoft extension to C and C++ to handle certain exceptional code situations, such as hardware faults, gracefully."
>
> I'm pretty sure for other platforms it is also defined as part of unwinding, although I can't be bothered to hunt for the specification. It's not about C, it's about languages that are not C++ (consider JIT's for instance).
>

C code can call C++ code which can throw.

C code can also call D code with can throw and/or gc.

D attributes are all subtractive, meaning they remove capability from the called function. But C code can do anything.

On 8/19/2024 5:24 PM, Gregor Mückl wrote:
> The C function interface has no notion of C++ exceptions (AFAIK it's following C specs, not C++),

C's setjmp/longjmp use the same exception throwing method.

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.