On 26/07/2025 12:03 PM, Steven Schveighoffer wrote:
> On Friday, 25 July 2025 at 16:58:43 UTC, Richard (Rikki) Andrew Cattermole wrote:
>> Hello all!
>>
>> We've had a meeting on how error handling should work in D.
>>
>> Approved work:
>>
>> - Finalisers are brought back to the baseline behaviour. They will not be rewritten to sequences in the frontend.
> 
> Can you explain this? The link isn't very explanatory for those who don't understand the DMD codebase.
> 
> -Steve

Yeah sure.

Right now final statements are different behavior based upon if the trybody scope could throw an ``Exception`` class.

If they do not throw an ``Exception``, it will rewrite it so that it is a sequence: ``trybody; finalbody;``

Final statements are used for a lot of things, running destructors of structs, or ``scope(exit)`` for instance.

That's a problem, its half way between two cleanup strategies. Never run cleanup on throwing of an ``Error`` or always cleaning up when ``Error`` is thrown.

An example of this behavior is the following code, where the destructor will run:

```d
void do1() {
	assert(0);
}

void main()
{
    static struct S
    {
        ~this()
        {
            import std.stdio;
            writeln("destructor ran!");
        }
    }

    S s;
    do1;
}
```

Bringing this back to baseline behavior of no rewrites, means that we can pick which strategy people want to use.

On Saturday, 26 July 2025 at 19:55:17 UTC, Richard (Rikki) Andrew Cattermole wrote:
> On 26/07/2025 12:03 PM, Steven Schveighoffer wrote:
>> On Friday, 25 July 2025 at 16:58:43 UTC, Richard (Rikki) Andrew Cattermole wrote:
>>> Hello all!
>>>
>>> We've had a meeting on how error handling should work in D.
>>>
>>> Approved work:
>>>
>>> - Finalisers are brought back to the baseline behaviour. They will not be rewritten to sequences in the frontend.
>> 
>> Can you explain this? The link isn't very explanatory for those who don't understand the DMD codebase.
>> 
>> -Steve
>
> Yeah sure.
>
> [...]

Unfortunately the explanation isn't very clear for me. Am I correct to think that this will ensure structs in `nothrow` functions now get their destructors run on assert / throw Error?

On 27/07/2025 9:12 AM, Sebastiaan Koppe wrote:
> On Saturday, 26 July 2025 at 19:55:17 UTC, Richard (Rikki) Andrew Cattermole wrote:
>> On 26/07/2025 12:03 PM, Steven Schveighoffer wrote:
>>> On Friday, 25 July 2025 at 16:58:43 UTC, Richard (Rikki) Andrew Cattermole wrote:
>>>> Hello all!
>>>>
>>>> We've had a meeting on how error handling should work in D.
>>>>
>>>> Approved work:
>>>>
>>>> - Finalisers are brought back to the baseline behaviour. They will not be rewritten to sequences in the frontend.
>>>
>>> Can you explain this? The link isn't very explanatory for those who don't understand the DMD codebase.
>>>
>>> -Steve
>>
>> Yeah sure.
>>
>> [...]
> 
> Unfortunately the explanation isn't very clear for me. Am I correct to think that this will ensure structs in `nothrow` functions now get their destructors run on assert / throw Error?

Yes, that is correct.

Walter's approach where this does not happen will have a switch to enable (assuming he implements it).

On Saturday, 26 July 2025 at 21:12:02 UTC, Sebastiaan Koppe wrote:
> Unfortunately the explanation isn't very clear for me. Am I correct to think that this will ensure structs in `nothrow` functions now get their destructors run on assert / throw Error?

OpenD implemented it back in May:

https://github.com/opendlang/opend/commit/40e11759a82175b2f5edfe855c53a75ce88f176c

So you can always run a test case through the opend compiler to see what happens. Try this for example:

```
bool destroyed;
struct A {
        ~this() {
                destroyed = true;
        }
}

void foo() nothrow {
        assert(0);
}

void thing() {
        A a;
        foo();
}

void main() {
        try {
                thing();
        } catch(Throwable t) {
        }
        assert(destroyed);
}
```

You'd certainly expect `A`'s dtor to be called at the end of `thing`, but with upstream, that's not actually the case, since it thinks the function doesn't do anything that could throw (`foo` being marked `nothrow` is important to get this result), and thus never bothers setting up the `finally` block internally to call that dtor, it just tries to do it at normal function return.

assert (and range error, or null pointer error - also implemented in opend a couple months ago, etc) ignore nothrow though, making it possible to break this assumption. Even if you never *caught* the `Throwable` like I did here, you still might notice the missing side effects of the destructor in other ways like if it did something outside your process.

On Sunday, 27 July 2025 at 01:05:57 UTC, Adam D. Ruppe wrote:
> On Saturday, 26 July 2025 at 21:12:02 UTC, Sebastiaan Koppe wrote:
>> Unfortunately the explanation isn't very clear for me. Am I correct to think that this will ensure structs in `nothrow` functions now get their destructors run on assert / throw Error?
>
> OpenD implemented it back in May:

Yes I saw you mention it in the mile-long thread on errors. Makes a lot of sense. Might have to try out opend one day.