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