C# 7.x: accessing fixed fields without pinning

[RexJaeschke]

While I think my solution allows the newer behavior, it might be too permissive.

See 'The main “challenge discussion in https://github.com/dotnet/csharplang/blob/main/proposals/csharp-7.3/indexing-movable-fixed-fields.md.

[BillWagner]

converted to draft: C# 7 feature.

[jskeet]

This isn't an area I'm particularly expert in, but it does look like this is too permissive.

In particular, I think it would imply that the second example in the feature doc should be valid - and it's not. The feature only adds the ability for the first example to become valid without a fixed statement.

I honestly don't know how we'd allow the indexing part at the moment. One for discussion, certainly.

[KalleOlaviNiemitalo]

Current compiler behaviour (SharpLab):

unsafe struct C {
    fixed int buf[9];
    void M() {
        _ = this.buf[6]; // OK   
        _ = (this.buf)[6]; // error, needs fixed statement
    }
}

So this seems to require a new rule that specifically allows the syntax for indexing a fixed-size buffer.

[KalleOlaviNiemitalo]

Fixed-size buffers cannot be nested

unsafe struct C {
    public fixed int buf[9];
}

unsafe struct D {
    fixed C buf2[5]; // error, C not a fixed-size primitive type
    void M() {
        _ = (this.buf2[1].buf)[3];
    }
}

so the new rule need not state that the movability of this.buf2[1].buf depends on the movability of this.buf2[1] because such a construct cannot be defined anyway.

[BillWagner]

For discussion in the meeting. I think this works. (I can't make a suggestion on the PR, because the only change is a deletion):

Instead of deleting the single line, modify it as follows:

• Otherwise, if E is a moveable variable (§22.4), the expression E.I must be one of the following, or a compile-time error occurs:
  • A fixed_pointer_initializer (§22.7)
  • An element_access (§11.710) expression where I is fixed-size buffer (§22.8).

[KalleOlaviNiemitalo]

@BillWagner problems with that wording:

• E.I does not match the element_access syntax defined in §11.7.10.1. Instead you could say E.I is the primary_no_array_creation_expression in element_access. It would be even better to reference the pointer_element_access syntax in §22.6.4.
• The last list item "Otherwise, E references a fixed variable and the result of the expression is a pointer […]" is not reached so you need to specify the semantics of the E.I[E0] expression somewhere else. The type conversion of E0 apparently matches §22.6.4 but I'm not sure whether fixed-size buffer element access should be described as involving a pointer type.

[BillWagner]

Update based on above comment:

For discussion in the meeting. I think this works. (I can't make a suggestion on the PR, because the only change is a deletion):

Instead of deleting the single line, modify it as follows:

• Otherwise, if E is a moveable variable (§22.4), the expression E.I must be one of the following, or a compile-time error occurs:
  • A fixed_pointer_initializer (§22.7)
  • An pointer_element_access (§22.6.4) expression where I is fixed-size buffer (§22.8).
• Otherwise, E references a fixed variable and the result of the expression is a pointer to the first element of the fixed-size buffer member I in E. The result is of type S*, where S is the element type of I, and is classified as a value.

Note that the last bullet item is in the spec now. I added it to the comment because I thought its presence addresses @KalleOlaviNiemitalo 's second bullet point above. (Namely, if E isn't a moveable variable, this bullet applies).

[BillWagner]

ping @jskeet for Meeting agenda

[jskeet]

@BillWagner: Not quite sure what you mean - it's got the "meeting: discuss" label, so I'd expect us to just find it that way. Anything else you wanted me to do?

[BillWagner]

@BillWagner: Not quite sure what you mean - it's got the "meeting: discuss" label, so I'd expect us to just find it that way. Anything else you wanted me to do?

Nope. Just hoping we can resolve this one today.

[BillWagner]

Results from committee meeting:

We think the latest change is close, but may need refinement.

@MadsTorgersen and @jskeet tagged for review

@KalleOlaviNiemitalo Can you add a comment on the confused emjoi above?

[KalleOlaviNiemitalo]

@BillWagner, E.I (where E is an expression and I is an identifier) cannot match the pointer_element_access syntax either, although it can match the primary_no_array_creation_expression part of that. So the change in the proposed wording does not address the first bullet point in #239 (comment).

§22.6.4 Pointer element access defines the syntax like so:

pointer_element_access
    : primary_no_array_creation_expression '[' expression ']'
    ;

i.e. it would have to end with ']', which E.I cannot do.

[BillWagner]

Ping @jskeet @MadsTorgersen

I've updated this to restore the previous language for member access, and add new text for element_access (E[I]), that follows the rules for pointer_element_access. This should be ready for a final review and (hopefully) merging.

[Nigel-Ecma]

I think this is too permissive as is, it should only capture the case of E.I[J].

[BillWagner]

Current status as of March 20:

I think I've addressed all remaining comments from Nigel and Jon. I didn't resolve the conversation from Jon above. It would be good to have additional opinions here.

[jskeet]

Just to be clear, this is two new features:

• x.Buffer[index]
• &x.Buffer

... neither of which would have been valid before? Assuming that's the case, this is fine.

[BillWagner]

Just to be clear, this is two new features:

• x.Buffer[index]
• &x.Buffer

... neither of which would have been valid before? Assuming that's the case, this is fine.

Only the first is valid without fixed. The second returns a pointer, so requires fixed. The two features that now don't require pinning are:

var n = x.Buffer[index];
x.Buffer[inces] = n + 2; // Using the element in the buffer as a variable

[jskeet]

Just to be clear, this is two new features:

• x.Buffer[index]
• &x.Buffer

... neither of which would have been valid before? Assuming that's the case, this is fine.

Only the first is valid without fixed. The second returns a pointer, so requires fixed.

Okay - so leaving aside pinning, was the second valid before now? I'm only mentioning it because it looks like it's new text.

[BillWagner]

Okay - so leaving aside pinning, was the second valid before now? I'm only mentioning it because it looks like it's new text.

Yes, that's correct.

[MadsTorgersen]

Looks good!

[Nigel-Ecma]

LGTM