Extend [DoesNotReturn] attribute impact to execution flow analysis

[AlexRadch]

The compiler can compile a switch expression that throws an exception directly.
However, the compiler can not compile a switch expression that calls a method with the [DoesNotReturn] attribute.

using System;
using System.Diagnostics.CodeAnalysis;

for (var i = 0; i < 100; i++)
{
    Console.WriteLine(i switch 
        {
            < 10 => "🌄",
            < 20 => "🌄🌄",
            _ => throw new Exception("Always"), // Successful compilation
        }
    );
    
    Console.WriteLine(i switch 
        {
            < 10 => "🌄",
            < 20 => "🌄🌄",
            _ => Throw(), // Compilation error
        }
    );
}

[DoesNotReturn]
static void Throw() => throw new Exception("Always");

I suggest extending [DoesNotReturn] attribute impact to execution flow analysis. This will allow us to compile the code that calls the method that always throws an exception.

// Call a method with the [DoesNotReturn] attribute
Throw();

// Will be compiled into the following code
Throw();
UnreachableFlowException.Throw(); // Protect from incorrect [DoesNotReturn] attribute. This method is included in the standard library and is well-known to the compiler.

This will protect the execution flow from setting the [DoesNotReturn] attribute incorrectly.

Related discussions

• Pattern Matching should respect [DoesNotReturn] and [DoesNotReturnIf] #7795

[333fred]

As mentioned in the previous discussion, this is covered by #538. DoesNotReturn does not impact execution analysis by design, like all other nullability features, and if we wanted to do so, we'd need to actually design a language feature for that. never is that feature.

[DavidArno]

"never is that feature."

Being spoken in the style of Yoda, concerns I have. "Never" feel prophetic at times. 😉

[AlexRadch]

As mentioned in the previous discussion, this is covered by #538. DoesNotReturn does not impact execution analysis by design, like all other nullability features, and if we wanted to do so, we'd need to actually design a language feature for that. never is that feature.

It is enough to throw an exception after calling a method with the [DoesNotReturn] attribute. This is what I suggest above.

// Call a method with the [DoesNotReturn] attribute
Throw();

// Will be compiled into the following code
Throw();
UnreachableFlowException.Throw(); // Protect from incorrect [DoesNotReturn] attribute. This method is included in the standard library and is well-known to the compiler.

[siegfriedpammer]

when the same thing can be implemented just as well without adding new entities.

I think, if it's a compiler feature, it would be no problem/nice to have dedicated syntax, defining a new type seems to be the easiest part.

If you are OK with custom attribute and a call to a throw helper injected after each call, you might be able to achieve this feature today by using some IL rewriting library like Fody and a Roslyn analyzer to produce diagnostics/errors if something is wrong.

[GabeSchaffer]

I don't think IL rewriting will work because the problem is a spurious compiler error.

[AlexRadch]

If you are OK with custom attribute and a call to a throw helper injected after each call, you might be able to achieve this feature today by using some IL rewriting library like Fody and a Roslyn analyzer to produce diagnostics/errors if something is wrong.

Here we write ideas on how to improve C# and its compiler for everyone.

[siegfriedpammer]

Here we write ideas on how to improve C# and its compiler for everyone.

And the members of the language design team have already answered how they would go about changing the language to solve your problem. This discussion should have ended there.

Thank you for reminding me that I should stop reading and interacting with large parts of the discussions section of this repository.

[333fred]

Folks, let's please keep this civil.