RAII requires exceptions to be correct. I hesitate to say it it has RAII otherwise.

Exceptions have two issues:

1. D exceptions currently require the GC. There is a Pull Request to fix that, but it isn't incorporated yet.

2. More problematic is the Dwarf exception handling mechanism requires a language specific "personality" handler. This is supplied by the D runtime library. Trying to trick the C runtime library one into working with D isn't a solved problem at the moment.

Rust uses RAII all over the place and doesn't have exceptions :).

Why does RAII require exceptions? RAII is routinely used in C++ with -fno-exceptions.

Because D code may sit in between code that throws and exception and code that handles it. Without EH support, the RAII destructor won't get called when the stack is unwound.

Isn't it generally undefined behaviour to have exceptions pass through code that isn't compiled with support for them? I.e. not running some destructors is the least of your worries if an exception hits C/-fno-exceptions/-betterC code.

Undefined behavior or not, implementations of languages in gcc and Windows tend to support it, even if the language itself does not. I consider it my job to make this work if at all practical, because users do not like ugly surprises.

I don't know how Rust's RAII deals with exceptions thrown by lower level code. If someone better acquainted with Rust could chime in here, it would be interesting.

> I don't know how Rust's RAII deals with exceptions thrown by lower level code.

Unwinding across an FFI boundary is considered undefined behavior.

https://doc.rust-lang.org/reference/behavior-considered-unde... last bullet point.

That's exactly what I wanted to know. Thanks!

Full D is compatible with foreign exceptions and unwinding. I'll see about making D as Better C also compatible, but I suppose Rust's precedent makes it acceptable to not handle it.

No problem!

This isn't my super strong area of expertise, but don't you have to specify how the unwinding works? I believe this is part of the reason why Rust punted; you'd have to specify exactly what kind is supported. (Rust uses libunwind for panics, incidentally.)

The how is handled by providing a language-specific "personality" function in the generated exception tables. The D runtime library has one for D. But with D as Better C, I'd have to find a way to make the C personality function work for D.

Ah right, makes sense. Thanks :)

If you mean lower level Rust code, there are no exceptions. Errors are just regular values encoded in the type system. If you're familiar with OCaml optionals and results, it's the same thing

There's a subtlety here: panics are exceptions, but they can be disabled without also disabling RAII.

How does it work if an exception gets thrown through a C stack frame that has outstanding resources (for instance, pointers that are freed later in the frame)? Are you referring to manual SJLJ?

In any case, it seems like C manual destruction has exactly the same problems as with RAII, because fundamentally the issue is passing exceptions through something that doesn't understand it, rather than with RAII.

Gotcha. C++ has the same problem when its exceptions are thrown through C or -fno-exceptions C++ frames.

If that's the only hold-up, IMO the way to go is to abort at the boundary, when an exception would propagate into frames without unwind tables. RAII is too valuable to do without!

> RAII requires exceptions to be correct.

I'm not exactly sure what you mean here, but all I really want is guaranteed destructors. Can we just have those?

> Can we just have those?

It's a good thought. D as Better C is new for us, and we'll be flexible in making it work better.

RAII in not removed by design. It is just work in progress. It will be added to -betterC when its implementation is more mature for this mode.