Allow unchecked in method or class signature, just like unsafe

[keichinger]

I was wondering why the unchecked context is not allowed as part of the method or class signature?
Apart from having the same benefits as unsafe at method or class signature level, this change would introduce more consistency between both keywords, which is something I have always really appreciated about C# and the .NET Framework.

Before:

private static void Foo()
{
    unchecked
    {
        // Unchecked code
    }
}

After:

private unchecked static void Foo()
{
    // Unchecked code
}

Applied to a class:

unchecked class Foo
{
    // Class definitions
}

Is there anything I have missed why this hasn't been made possible in the past or was it simply the (probable) limited usage of unchecked in C# compared to unsafe?

[jnm2]

Yes, please! Every time I implement GetHashCode I end up wrapping the entire method body with unchecked and braces. I would also add checked to go with that.

[gafter]

Unlikely because as a rule we like to avoid letting implementation details about a method leak outside its body.

[keichinger]

@gafter I understand, although isn't that the same as with unsafe?

[jnm2]

@gafter Is it really leaking information about implementation details? It's not part of the method signature. unsafe and async are also purely implementation details, and they don't leak information outside the method definition either.

[gafter]

@jnm2 Yes, unsafe and async are examples of the kind of things we'd prefer to avoid.

[jnm2]

@gafter I see this as a keystroke and multiple line saving feature, like auto get and set and expression bodies. Along the same lines we'd like to be able to use throw in an expression body. Along the same lines also we'd like to have this feature. Just so I understand, given that the method is identical from the outside, who actually loses out if you add an unchecked method definition?

[gafter]

We are now taking language feature discussion on https://github.com/dotnet/csharplang for C# specific issues, https://github.com/dotnet/vblang for VB-specific features, and https://github.com/dotnet/csharplang for features that affect both languages.