On Sunday, 6 July 2025 at 23:53:54 UTC, Timon Gehr wrote:

Technically, memory safety is supposed to be guaranteed by not letting you catch unrecoverable throwables in @safe. When you do catch them, you're supposed to verify that any code you have in the try block (including called functions) doesn't rely on destructors or similar for memory safety.

I understand this is problematic, because in practice pretty much all code often is guarded by a top-level pokemon catcher, meaning destructor-relying memory safety isn't going to fly anywhere. I guess we should just learn to not do that, or else give up on all nothrow optimisations. I tend to agree with Dennis that a switch is not the way to go as that might cause incompatibilities when different libraries expect different settings.

In idea: What if we retained the nothrow optimisations, but changed the finally blocks so they are never executed for non-Exception Throwables unless there is a catch block for one? Still skipping destructors, but at least the rules between try x; finally y;, scope(exit) and destructors would stay consistent, and nothrow wouldn't be silently changing behaviour since the assert failures would be skipping the finalisers regardless. scope(failure) would also catch only Exceptions.

This would have to be done over an edition switch though since it also breaks code.

On Monday, 7 July 2025 at 21:44:49 UTC, Dukc wrote:

Meant that should learn not to rely on destructors (or similar finalisers) for memory safety.

Not that should learn out of Pokemon catching at or near the main function.

On Monday, 7 July 2025 at 21:54:23 UTC, Dukc wrote:

I can see a perfect storm with destructors being skipped in combination with having stack memory in a multi-threaded program, so that the very act of skipping destructors is what causes memory corruption. It breaks the structure the programmer diligently created.

If D can't gracefully shutdown a multi-threaded program when an Error occurs - i.e. catch the Error at the entry point of a thread, send upwards to the main thread and cancel any threads or other execution contexts (e.g. GPU) - then the only sane recommendation is to avoid all asserts or call abort on the spot. Which would be very unfortunate.

On Tuesday, 8 July 2025 at 07:47:30 UTC, Richard (Rikki) Andrew Cattermole wrote:

Wrong! There are, like Dennis wrote:

void start() nothrow;
void finish() nothrow;

void normal() {
    start();
    finish();
}

struct Finisher { ~this() {finish();} }
void destructor() {
    Finisher f;
	start();
}

void scopeguard() {
    scope(exit) finish();
    start();
}

void finallyblock() {
    try {
        start();
    } finally { finish(); }
}

This means that the three latter functions execute finish() on unrecoverable error from start() if it is designated throwing, but not if it's nothrow.

My suggestion would make it so that the functions aren't executed in either case. You would have to do

try start();
catch(Throwable){}
finally finish();

instead, as you might want to do already if you wish the nothrow analysis to not matter.

I'm assuming such a conversion is done somewhere at the compiler anyway. After all, the finally block is essentially higher level functionality on top of catch. try a(); finally b(); is pretty much the same as

Throwable temp;
try a();
catch (Throwable th) temp = th;
try b();
catch (Throwable th)
{   // Not sure how exception chaining really works but it'd be done here
    th.next = temp;
    temp = th;
}
if(temp) throw temp;

On Sunday, 6 July 2025 at 23:53:54 UTC, Timon Gehr wrote:

I'd say nothrow de-facto has this meaning (per Walter's intention), and catching Error is currently @system, although only implied by documentation and not enforced by the compiler.

So I take it opend changed that, being okay with the breaking change? Because @safe constructors of structs containing fields with @system destructors will now raise a safety error even with nothrow.

Indeed, I tried enabling it by default in my original PR but it broke certain Fiber tests, and there were some (legitemate) doubts about multi-threaded programs and interfering with debuggers so that's still todo.

Specifically related to stack unwinding. The logic "throw Error() should consistently run all cleanup code because a null dereference just segfaults and that sucks" escapes me, but:

That tracks. I guess the confusion came from two discussions happening at once: doubling down on throw Error() and doubling down on abort() on error.

Some people in this thread argue that code should be Exception safe even in the case of an index out of bounds error. If that's the case, the throw / nothrow distinction seems completely redundant. Imagine the author of a library you use writes this:

mutex.lock();
arr[i]++;
mutex.unlock();

Instead of this:

mutex.lock();
scope(exit) mutex.unlock();
arr[i]++;

The idea that best-case Errors (caught right before UB) function just like Exceptions breaks down. nothrow is useless if you don't want anyone to write different code based on its presence/absence, right?

While I can't say I have the numbers to prove that its performance is important to me, I currently like the idea that scope(exit)/destructors are a zero-cost abstraction when Exceptions are absent. Having in the back in the mind that it would be more efficient to manually write free() at the end of my function instead of using safe scoped destruction might just (irrationally) haunt me 😜.

I'd usually agree wholeheartedly, but in this situation it's "correctness after something incorrect has already happened" vs. "performance of the correct case" which is more nuanced.

On Tuesday, 8 July 2025 at 10:47:52 UTC, Richard (Rikki) Andrew Cattermole wrote:

Whether a function is nothrow affects whether a call expression 'can throw'

https://github.com/dlang/dmd/blob/9610da2443ec4ed3aeed060783e07f76287ae397/compiler/src/dmd/canthrow.d#L131-L139

Which affects whether a statement 'can throw'

https://github.com/dlang/dmd/blob/9610da2443ec4ed3aeed060783e07f76287ae397/compiler/src/dmd/blockexit.d#L101C23-L101C31

And when a 'try' statement can only fall through or halt, then a (try A; finally B) gets transformed into (A; B). When the try statement 'can throw' this doesn't happen.

https://github.com/dlang/dmd/blob/9610da2443ec4ed3aeed060783e07f76287ae397/compiler/src/dmd/statementsem.d#L3421-L3432

Through that path, nothrow produceds better generated code, which you can easily verify by looking at assembler output of:

void f();
void testA() {try {f();} finally {f();}}

void g() nothrow;
void testB() {try {g();} finally {g();}}

I have no idea what this distinction is supposed to say, but "there is no nothrow specific optimizations taking place" is either false or pedantic about words.