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.

On 09/07/2025 8:24 AM, Sebastiaan Koppe wrote:
> On Tuesday, 8 July 2025 at 19:55:13 UTC, Dukc wrote:
>> That's an interesting idea actually. I think we still should have some mechanism for another thread to handle a thread death but maybe catching another error at another thread isn't the way.
>>
>> Instead, maybe some thread could register a death handler delegate (thread gravedigger?) that is called if another thread dies. If there is no gravedigger, or if the only gravedigger thread itself dies, then all others would immediately receive an unrecoverable error, and the error from the dead thread would be what is reported.
> 
> That is similar to what happens with structured concurrency. For every execution context there is always an owner to which any Error gets forwarded to, all the way up to the main thread.
> 
> It would be straightforward to change that so that it terminates the process on the spot, but I prefer graceful shutdown instead.

I've considered something like this, and I do think we need to make it configurable.

Have a method on a thread that "filters" by-ref any caught exception (Throwable) at the thread entry point.

Ideally the default is to kill the process, so that you don't have silent death of threads.

If you want to change it, you can override the method.

The default implementation could also check a global function pointer to do the grave digger concept of Dukc's.

I am concerned that to set such a default could break existing programs, so I'm not sure what to do about that.

On 09/07/2025 8:17 AM, Dennis wrote:
> 1. `nothrow` currently affects code generation
> 2. `nothrow` currently affects whether `throw Error` skips finally blocks in try-finally blocks
> 3. `nothrow` can be written down in source code or inferred, which is treated the same
> 4. scope(exit) and destructor calls are lowered to try-finally, making them behave equivalently
> 5. All this logic currently exists in the frontend
> 6. It is possible to remove the nothrow optimization by changing frontend logic
> 7. There's a discussion going on whether that's desirable.
> 
> Do you disagree with any of these, or is there a different point you're trying to make?

Different way of describing it, but for all intents in purposes we agree.