12.7.7.2 and 12.18.2 Array access evaluation order for assignments

[jskeet]

13.7.7.2 (array access) suggests that evaluating an array access expression performs nullity and index checks.

13.18.2 (simple assignment) states for an assignment x = y:

• If x is classified as a variable:
  • x is evaluated to produce the variable.
  • y is evaluated and, if required, converted to the type of x through an implicit conversion (§12.2).

That all sounds fine, but my understanding of reality is that the nullity check and array index check are only performed after y is evaluated. Sample code to show that...

Null check comes after RHS

using System;

public class Test
{
    static void Main()
    {
        int[] array = null;
        array[10] = SideEffect(); // Prints "Side effect" then throws
    }

    private static int SideEffect()
    {
        Console.WriteLine("Side effect");
        return 10;
    }
}

Index check comes after RHS

using System;

public class Test
{
    static void Main()
    {
        int[] array = new int[5];
        array[10] = SideEffect(); // Prints "Side effect" then throws
    }

    private static int SideEffect()
    {
        Console.WriteLine("Side effect");
        return 10;
    }
}

I have very vague recollections of this being properly specified somewhere, but I can't easily find it - and assuming it does exist, I think we should have a reference to it within at least one of these sections.

Assigning to Mads initially as he may well know what's going on...

[Nigel-Ecma]

Well a[i] is an array access (§13.7.7.2) which doesn't explicitly cover a[i] = e, for that we go to Indexers ($16.9) where we find e is appended to the index list (i) to produce the argument list.

Both §13.7.7.2 & $16.9 give the evaluation order as:

1. a
2. argument list: i, e in order (§13.6.2)
3. null check
4. index check

(for a user-defined indexer step 4 is up to the indexer).

So I think it is all there, though maybe not as straightforward as you might wish.

[jskeet]

It's not at all clear to me that 16.9 (Indexers) is also meant to include array access - especially as there are comparisons with array access within there.

I'm not sure why 13.7.7.2 shouldn't include a[i] = e;... let's discuss.

[jskeet]

Punt to C# 6 to discuss whether or not to modify the spec to match the behaviour, which we acknowledge is different from the current spec. (We would like to have made the behaviour match the spec, but that would be too much of a breaking change now.)

[jskeet]

All comments prior to this one were before we removed section 7. I've updated the title only.

[jskeet]

Assigned to @MadsTorgersen to consider before the next meeting.

[MadsTorgersen]

Jon is right.

According to 12.7.7.1 Element access a[i] is an array access when a is of an array type.

In 12.7.7.2 Array access such an array access is classified as a variable, and it is described in detail how to compute the location referenced by the variable.

In 12.18.2 Simple assignment it is clear that the variable on the left-hand side (the array access) is computed before the right-hand side:

• If x is classified as a variable:
  • x is evaluated to produce the variable.
  • y is evaluated and, if required, converted to the type of x through an implicit conversion (§11.2).
  • If the variable given by x is an array element of a reference_type, a run-time check is performed to ensure that the value computed for y is compatible with the array instance of which x is an element. The check succeeds if y is null, or if an implicit reference conversion (§11.2.7) exists from the type of the instance referenced by y to the actual element type of the array instance containing x. Otherwise, a System.ArrayTypeMismatchException is thrown.
  • The value resulting from the evaluation and conversion of y is stored into the location given by the evaluation of x.
    ...

I think that the spec'ed semantics are the most elegant and orthogonal, and that the compiler behavior is essentially a bug. Of course it is out of the question to change the compiler behavior after 20 years of people depending on it. So our choices seem to be:

1. Do nothing. We leave this as a discrepancy caused by a compiler bug.
2. Change the spec to match compiler semantics.

If we want to pursue the latter, I think that we still want to classify an array access as a variable, so that it can continue to work the same elsewhere (including being ref'ed etc.). We would instead special-case assignment (probably both 12.18.2 Simple assignment and 12.18.3 Compound assignment) to handle arrays before other variables.

My inclination is to do nothing and live with the discrepancy. If we decide to go with the latter, I can try to draft the specific additions to those two sections.

[jskeet]

This isn't the first time we've come up against "Hmm - it's not right, but it's not worth changing." Places where if we were writing an annotated standard, we might have an annotation.

Perhaps we should consider something that could live within the standard, so that the information isn't lost (or separated from the standard, as it effectively is in a closed issue - think Raiders of the Lost Ark closing scene). It might make sense to remove such annotations from the Word conversion (at least optionally) so it would never be part of the official standard, but it would be useful to language archaeologists.