Preview Feedback: C# 13+ field backed properties

[xecrets]

The new field keyword available in preview of C# 13+ is very useful. Apparently the motivation for keeping it in preview, is the breaking change with introducing a new keyword field in a context where that actually quite frequently will cause a problem with ambiguity.

Since a long time, C# has had the verbatim identifier character '@' to ensure that when a keyword is used as identifier name, it'll be interpreted as an identifier instead, for example @default etc.

I would propose the introduction of a keyword character or syntax with the reverse meaning. Although I'm not sure what character will work without conflict, I think perhaps the '#' character would work - and it's also kind of nice, as it alludes to the '#' in C# to indicate that it's a language component. The only conflict I can think of offhand is the preprocessor directives, but then again - if '#' indicates a keyword, the #if etc. would be easily interpreted as a preprocessor if. I think...

It would be acceptable anywhere a keyword can syntactically appear as an identifier, so you could use it as #field to ensure that even if there's an identifier in scope with the name field, it would be interpreted as the keyword instead.

In fact, the only thing that makes the current situation manageable is the syntax highlighting provided by all IDE's. Without syntax highlighting it's not obvious just what interpretation an identifier that is also used as a keyword is given.

If the '#' character doesn't work, I'm sure there is some other non-conflicting compact syntax that can do the job. But assuming '#' would work we could then have #field, #default etc. The '#' would be allowed anywhere the '@' verbatim character is allowed before an identifier.

Back to the field preview feature. For this feature, I'd propose that the keyword modifier character/syntax be required for field. This will remove the breaking change problem, as there is no conflict anymore.

For the future, I would suggest a gradual move to require the keyword modifier character for all such cases, starting with an info level intellisense suggestion, later to a warning (that could be disabled, and thus make for a soft break), and possibly in the further future an error.

This would remove the dependence on syntax highlighting to indicate how a keyword/identifier is interpreted by the compiler, and also solve the problem of the field breaking change problem, and perhaps open up for similar new features being non-breaking changes.

(This seems such an obvious thing, so even though I've not been able to find a similar proposal.... #7033 relates to this but not quite in the same way. If this has already been discussed and dismissed for reasons that are obvious to everyone but me, sorry for taking up your time!)

[CyrusNajmabadi]

It was a very intentional part of the design that we use field. We originally considered different syntaxes that would not have BC concerns, but we rejected them as we explicitly do not want the language to look like it has differing syntax for things like field vs value (another contextual semantic keyword in a property).

Without syntax highlighting it's not obvious just what interpretation an identifier that is also used as a keyword is given.

That's life tbh. That's how 'var', and all our other contextual semantic keywords, works. In time people get used to it :)

[xecrets]

Well...

Maybe I was not expressing the idea quite as clearly as I thought. I am not proposing that field be the only keyword to use the keyword disambiguating character, I was proposing the addition of the '#' (or something else) as a keyword character in all places where keywords may be ambiguous with identifiers. You could for example have @value = #value; or @field = #field; or #field = @field; in a property accessor which would make the intent much clearer.

There would be no differing syntax for field vs value or for any other similar keywords - the only thing to get around the breaking change problem would be to make the # required for the field reference in a property accessor for example.

Even without the proposed slight asymmetric requirement for field it's still useful I think. Then again I do realize that it's almost never as easy as it seems to change something in a language, so there are probably caveats I'm not thinking about here, complicating things again. As you said, you've considered various options, and I'm sure something like this was also considered - or rejected immediately without consideration for some obvious reason I'm missing.

I don't quite get the var reference in this context, although I might add that the addition of var everywhere (not just for anonymous types) is one of my least favorite additions to the language. IMHO it's caused a lot of damage to readability and thus maintainability of a lot of code. It was exacerbated by early suggestion engines proposing the change to var everywhere it was possible. But that's just me, and it's off topic too.

Saying "in time people get used to it" as a rationale doesn't quite ring my bell either ;-) .

Anyway, I thought it would be fun to hear some feedback here, and now I did! Thanks!

[CyrusNajmabadi]

This will remove the breaking change problem, as there is no conflict anymore.

This is a misunderstanding of the space. We want breaking changes here. We believe it will be better for the ecosystem to have a clean and uniform syntax for properties, where 'field' just is the keyword with this meaning, just like any other keyword in the lang. It's a non-goal to have a non-BC approach, and we explicitly rejected several options along the way that would have had no BC concerns.

[xecrets]

Ok, that was not the impression I got from the presentation on .NET Conf 2024. It seemed the reason field was not made part of C# 13 but instead a preview, was the concern of the breaking change.
Don't get me wrong, I'm generally a fan of breaking changes, when they serve to correct past decisions that in hind sight turns out to be less than perfect. When breaking changes are 'forbidden', it may make new features less elegant than they could be.
I still think the addition of a keyword special character to mirror the verbatim special character does add some benefits, regardless of the field feature in particular.
Anyway, thanks for taking the time to respond!

[hez2010]

It seemed the reason field was not made part of C# 13 but instead a preview, was the concern of the breaking change.

This is not true. The field was shipped as a preview feature because there's still work around nullable analysis for field need to be done before the feature can be moved out of preview.

[HaloFour]

Certainly worth the opportunity to review how the syntax feels and what concerns we might want to voice before it goes GA. For example, I think there are a couple of details of the feature which might trip up developers in unexpected ways. Sure, the compiler is going to emit warnings, but those are easy to ignore even when it is clear what is going to happen. For example:

public int Foo {
    get {
        int field = CalculateSomeField();
        field += SomeAddiitonalCalculation();
        return field;
    }
}

This is code that will compile successfully, albeit with some warnings. For example, the variable declaration will warn that the variable isn't used, as the result of CalculateSomeField() is effectively dropped on the floor as all subsequent references to field are of the backing field and not that local variable. The end result is the property ends up returning nonsense.

Another example:

public int Foo {
    get {
        return fields.Select(field => field).FirstOrDefault();
    }
}

Similar situation, the lambda declares a parameter called field, but the lambda body instead captures the backing field.

IMO, I would prefer it if the compiler forbid declarations of the name field within property accessors. Force developers to qualify them with @ both on declaration and within expressions so that it appears consistent and the developer can quickly understand to which they are referring. Members must be qualified by this, e.g. this.field.

Yes, I am aware that there are some parts in C# where a certain contextual keywords can be used both qualified and unqualified in the same scope, but I would suggest that they generally would result in compiler errors when used incorrectly, not subtly change the intended meaning of that code.