Proposal: 'checked' / 'unchecked' as a type and method modifier

[jamesqo]

Background

checked and unchecked are C# keywords that control behavior in the event of an integer overflow. I frequently use checked arithmetic in code I write, because it eases debugging and reduces the chance of errors slipping by silently. I also prefer to be explicit by putting checked in the code, rather than relying on a project file to tell the compiler to use checked/unchecked arithmetic by default.

As a result, I have many methods in my codebase that do a little arithmetic that look like

// Real code from my project
public static int Choose(this int n, int k)
{
    double numerator = n.Factorial();
    double denominator = k.Factorial() * checked(n - k).Factorial();
    return checked((int)(numerator / denominator));
}

Where I wrap every arithmetic operation with checked(). I could also put the whole method inside a checked { } block to avoid forgetting checked() lest I introduce another operation, but I'm hesitant to do so because blocks add another level of indentation:

public static int Choose(this int n, int k)
{
    // Not convenient to write every time you want to do arithmetic
    checked
    {
        ...
    }
}

Proposal: checked / unchecked as a method modifier

I propose making checked / unchecked a valid method modifier. The following forms of code will be allowed if this is implemented:

public checked void M() { /* Arithmetic in here is checked */ }

public unchecked void N() { /* Arithmetic in here is unchecked */ }

This would be semantically equivalent to writing the following today:

public void M() { checked { ... } }

public void N() { unchecked { ... } }

Here is how my above example would look like using this new feature.

public static checked int Choose(this int n, int k)
{
    double numerator = n.Factorial();
    double denominator = k.Factorial() * (n - k).Factorial();
    return (int)(numerator / denominator);
}

Precedent: unsafe

If approved, this feature would not be entirely unprecedented. unsafe, which allows developers to demarcate regions of 'unsafe' code where they can use pointers, is already valid as a block keyword and as a method modifier. You can write both of the following today:

public unsafe void M() { int* pointer = null; }

public void M() { unsafe { int* pointer = null; } }

It doesn't seem unreasonable to make the story the same for checked.

checked as a type modifier

unsafe brings me to my next point: should checked be allowed as a type modifier? While writing this proposal, I initially hesitated to allow it to be a type modifier because I didn't see the need for it. However, I have changed my mind: first of all, unsafe class / unsafe struct is allowed (so checked should follow precedent), and second, I do have many types where I use checked in multiple different methods. Instead of annotating each method with checked, it would be convenient to write it once and have it apply to the whole class.

If we allowed checked / unchecked to modify types, the following code would become valid:

public checked class C { ... }

public unchecked class C { ... }

Nested checked / unchecked

Intuitively, checked / unchecked on the inside should have stronger precedence than on the outside, so that is what is proposed here. Expressions > blocks > methods > types for determining what type of arithmetic is used.

public checked class C
{
    // Checked arithmetic used outside of M()
    public unchecked void M()
    {
        // Unchecked arithmetic used outside of checked block
        checked
        {
            // Checked arithmetic used outside of expression for r
            int r = unchecked(Environment.TickCount * Environment.TickCount); // Unchecked arithmetic used
        }
    }
}

Local functions

Like unsafe, checked / unchecked will be permitted on local functions. Local functions will have greater precedence than their containing method on using checked / unchecked.

public checked void M() { unchecked void N() { /* Unchecked arithmetic used here */ } }

public unchecked void M() { checked void N() { /* Checked arithmetic used here */ } }

Edit 5/9: These modifiers will not affect the type system or change method signatures; they are purely an implementation detail of types/methods marked with them. A derived class is not automatically checked if its base class is marked checked, for example. A virtual checked function will not make overrides automatically checked, either. Also, a couple of places where it doesn't make sense to use these modifiers will be banned from doing so:

• Interfaces
• Interface members
• abstract methods
• extern methods

Edit 5/11: This occurred to me while I was working on my project: allowing checked / unchecked methods would also help reduce code density in expression-bodied members. Consider the following snippet of code I was just editing:

public static Polynomial operator +(Polynomial left, Term right)
    => left.TryGetCoefficient(right.Degree, out int coefficient)
    ? left.SetCoefficient(right.Degree, checked(coefficient + right.Coefficient))
    : left.AddNewDegree(right);

I would like to eliminate the checked() because IMO, there's already enough going on in the method. However, to do that I would have to put the entire ternary expression in a checked { } block, forcing me to not use an expression-bodied member here. With the above proposal, that would not be necessary:

public static checked Polynomial operator +(Polynomial left, Term right)
    => left.TryGetCoefficient(right.Degree, out int coefficient)
    ? left.SetCoefficient(right.Degree, coefficient + right.Coefficient)
    : left.AddNewDegree(right);

[lachbaer]

public checked void M() { unchecked void N() { /* Unchecked arithmetic used here */ } }

Marking a complete method as 'checked' and then unchecking in it seems confusing to me! It counters the whole purpose of this proposal.

However having it on the method declaration's modifiers makes sense for those who use it. To me, not so much on a class' declaration, unless every method is decorated with un/checked, too. That's comparable to a static class where ever method must carry the static modifier as well.

[jnm2]

I like this just for symmetry with unsafe.

[jamesqo]

@lachbaer

Marking a complete method as 'checked' and then unchecking in it seems confusing to me! It counters the whole purpose of this proposal.

This is already allowed with checked blocks today, I'm just allowing it for the sake of consistency.

using System;
public class C {
    public void M() {
        checked
        {
            // Compiles fine!
            unchecked { int i = 3; int j = i + 1; }
        }
    }
}

However having it on the method declaration's modifiers makes sense for those who use it. To me, not so much on a class' declaration, unless every method is decorated with un/checked, too. That's comparable to a static class where ever method must carry the static modifier as well.

I get your point. However, I think static is different because it is critical to the interface of your method; omitting static drastically changes the meaning of your method and how it's called, so it's important that the developer can quickly identify whether a method is static. With un/checked, not so much; it's more of an implementation detail, and convenience takes priority. I think this is why today an unsafe class doesn't require its members to be marked unsafe.

[InPermutation]

How does this interact with inheritance and interfaces? Can you declare a method to be abstract checked?

(How) does it interact with overload resolution?

[jnm2]

Shouldn't be any different than the unsafe or async keywords. Internal implementation detail only, not visible externally to the type system.

[jamesqo]

@InPermutation

How does this interact with inheritance and interfaces? Can you declare a method to be abstract checked?

checked / unchecked should not play a role in the type system at all; it simply controls how certain types of expressions are evaluated inside of methods. abstract checked / extern checked would not make sense, because those types of methods have no body. Nor would checked make sense on interfaces.

If a base class is marked checked, then derived classes will not automatically use checked; they will use the default mode of arithmetic (usually unchecked, but depends on what options were passed to the compiler) unless the derived class is also marked checked / unchecked.

(How) does it interact with overload resolution?

It will not affect method signatures.

Edit: I just updated my proposal in response to all of the questions you raised.

[yaakov-h]

It seems strange to me that you desire new syntax to use just about everywhere in your project, instead of just defining the project property for making everything checked.

That said, I could see this being useful on a regular basis for public override unchecked int GetHashCode() { ... }.

[whoisj]

Let's leave checked and unchecked alone. Too few developers, in my experience, actually grok what these do and how they do it. The vast majority of cases developers really want unchecked but there are times when checked is a must (eg if (index + count > length) throw; is only legit when checked(index + length) > length).

[jnm2]

I don't think that's generally a good enough reason to leave them alone. Every GetHashCode implementation I ever write would look immediately better with an unchecked method modifier.

[whoisj]

@jnm2 I'm actually fine with method implementations accepting the modifier, but not abstract nor interface contracts.

[Joe4evr]

I'm actually fine with method implementations accepting the modifier, but not abstract nor interface contracts.

This sounds fair. It would be just like async in that respect, nothing more than an implementation detail (perhaps not even showing up in IntelliSense). And I guess you can't use unsafe on abstract or interface declarations unless the method signature explicitly returns/takes in a pointer? (I have never used unsafe myself, so I don't even know how valid that is.)

[jnm2]

@whois Definitely. It's an implementation detail invisible to the type system no different than async or unsafe.

[jamesqo]

@whoisj I agree. It wouldn't even make sense to have them as part of abstract / interface methods, in fact, since those methods have no body and no arithmetic expressions. That is why I banned that in my proposal (see my first edit).

[bondsbw]

Given the proposal #686, I'll throw out an alternate syntax for this scenario.

public static int Choose(this int n, int k) checked
{
    ...
}

or perhaps some would prefer this formatting:

public static int Choose(this int n, int k)
checked
{
    ...
}

[bondsbw]

For that matter, is there a way to use checked/unchecked for expression-bodied members? I see that this doesn't work in production:

public static int Choose(this int n, int k) => 
    checked
    {
        ...
    };

[jamesqo]

@bondsbw

Given the proposal #686, I'll throw out an alternate syntax for this scenario.

I think the current proposal is most consistent with how async, unsafe, etc. go on the left of the method name. It would be quite confusing if we did it one way for those modifiers and another way for checked / unchecked, and we might also run into discoverability issues.

For that matter, is there a way to use checked/unchecked for expression-bodied members? I see that this doesn't work in production:

public static int Add(int a, int b) => checked(a + b);

The way you have written it will not work because checked { } is a block statement which cannot be used as an expression, while checked() is an expression and therefore can be used in expression-bodied members.

[bondsbw]

Thanks, I was not aware of the expression form.

[jamesqo]

@gafter Does this proposal have enough popularity/sound reasonable enough to warrant discussion in an LDM?

[mikernet]

One problem I ran into as well is that as far as I can tell, there is no way to use a checked context for "statement-bodied" members like this:

public void Increment() => _position++;

None of these work:

public void Increment() => checked(_position++);
public void Increment() => checked { _position++; }

This proposal would fix that.