RFC: Change what assert does on error

[Richard (Rikki) Andrew Cattermole]

On 07/07/2025 3:48 AM, Dennis wrote:
> On Sunday, 6 July 2025 at 14:04:46 UTC, Richard (Rikki) Andrew 
> Cattermole wrote:
>> And then there is contracts that apparently need to catch AssertError.
> 
> That's an anomaly that should be solved on its own. It doesn't work with 
> -checkaction=C, and there's a preview switch for new behavior requiring 
> you to explicitly create in contracts that are more lenient than the 
> parent: https://dlang.org/changelog/2.095.0.html#inclusive-incontracts

Not possible due to function calls.

I did suggest to Walter that we might be able to change how contracts 
work for this in an edition, but it will be breaking to try to fix this.

> Perhaps we can open a new thread if there's more to discuss about that, 
> since this thread is already quite big and discussing multiple things at 
> the same time isn't making it easier to follow ;-)
> 
>> Why would it effect inference?
>>
>> Leave the frontend alone.
>>
>> Do this in the glue layer. If flag is set and compiler flag is set to 
>> a specific value don't add unwinding.
> 
> The frontend produces a different AST based on nothrow. Without any 
> changes, field destructors are still skipped when an error bubbles 
> through a constructor that inferred nothrow based on the assumption that 
> range errors / assert errors are nothrow.

```d
void unknown() nothrow;
void function(int) nothrow dtorCheck2b = &dtorCheck!();

void dtorCheck()(int i)
{
     static struct S
     {
         this(int i) nothrow {
             assert(0);
         }

         ~this()
         {
         }
     }

     S s;
     s = S(i);
     unknown;
}
```

Disable the if statement at: 
https://github.com/dlang/dmd/blob/3d06a911ac442e9cde5fd5340624339a23af6eb8/compiler/src/dmd/statementsem.d#L3428

Took me two hours to find what to disable. Inference remains in place.

Should be harmless to disable this rewrite, even if -betterC is on 
(which supports finally statements).

Do note that this rewrite doesn't care about ``nothrow``, or unwinding 
at all. This works in any function, which makes this rewrite a lot more 
worrying than I thought it was.

A better way to handle this would be to flag the finally statement as 
being able to be sequential. Then let glue layer decide if it wants to 
make it sequential or keep the unwinding.

On this note, I've learned that dmd is doing a subset of control flow 
graph analysis for Error/Exception handling, its pretty good stuff.