On 7/7/25 23:44, Dukc wrote:
> On Sunday, 6 July 2025 at 23:53:54 UTC, Timon Gehr wrote:
>> The insane part is that we are in fact allowed to throw in `@safe nothrow` functions without any `@trusted` shenanigans. Such code should not be allowed to break any compiler assumptions.
> 
> Technically, memory safety is supposed to be guaranteed by not letting you _catch_ unrecoverable throwables in `@safe`.

No. `@system` does not mean: This will corrupt memory. It means the compiler will not prevent memory corruption. At the catch site you are not able to make guarantees about the behavior of an open set of code, so making a catch statement a `@system` operation is frankly ridiculous.

Things that are _actually_ supposed to be true:
- Destructors should run when objects are destructed.
- The language should not assume that there will never be bugs in `@safe` code.
- It is easily possible to make a failing process record some information related to the crash.
- Graceful shutdown has to be allowed in as many cases as reasonably possible.

I.e., it's best to approach a discussion of what is "supposed" to hold from the perspective of practical requirements.

Coming up with some ideological restrictions that seem nice on paper and defending them in the face of obvious clashes with reality is just not a recipe for success.

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

This makes no sense. That can be your entire program.

> I understand this is problematic, because in practice pretty much all code often is guarded by a top-level pokemon catcher,

Yes.

> meaning destructor-relying memory safety isn't going to fly anywhere. I guess we should just learn to not do that,

No, that would be terrible. Memory safety being potentially violated is just the smoking gun, it's not the only kind of inconsistency that will happen.

I want my code to be correct, not only memory safe.

> or else give up on all `nothrow` optimisations.

Yes.

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

`nothrow` "optimizations" (based on hot air and hope) are what is problematic. It's not a sound transformation.

It's not like linking together different libraries with different settings is any more problematic than the current behavior.

I.e., the issue is not some sort of "compatibility", it is specifically the `nothrow` "optimizations".

If a library actually requires them in order to compile due to destructor attributes (which I doubt is an important concern in practice, e.g. a `@system` destructor with a `@safe` constructor does not seem like sane design), that's a library I will just not use, but it would still be possible using separate compilation or by making the "optimization" setting a `pragma` or something -- not an attribute that the compiler will sometimes implicitly slap on your code to change how it behaves.

> In idea: What if we retained the `nothrow` optimisations,

No. Kill with fire.

> but changed the finally blocks so they are never executed for non-`Exception` `Throwable`s unless there is a catch block for one?

Maybe. Can be confusing though.