Added: LDM Notes for March 24th, 2021

[333fred]

https://github.com/dotnet/csharplang/blob/main/meetings/2021/LDM-2021-03-24.md#

Agenda

1. Improved interpolated strings
2. field keyword

[alrz]

The proposal calls for resolving field to the backing field when there is no other identifier named that in scope. We thought about a few alternatives:

IMO none of the options seem attractive compared to what's originally proposed. It's not clear how the third option is even better? sure the chances of conflicts decrease, but it's there anyways and whoever wants to migrate to field props will have some renamings to do. So to me there's zero win there. The point is to not break existing code and it will be achieved via double binding, just like many other features.

To state the obvious, IDE will help to highlight field where it's a keyword, once you migrate, it's a matter of a code style option to completely gate field named fields which is up to devs if they wish to not confuse the two.

[HaloFour]

I agree, the alternatives here are quite unattractive.

Identifiers with a __ are reserved by C#

Are they? C# doesn't seem to have a problem with me naming a field __field: https://sharplab.io/#v2:D4WAUAAgzABBBMMDCMDe4abrAlgOwBcYB9YgMxwFMAbAExgF4YB2ADgE4BucAXyA

[CyrusNajmabadi]

'Reserved' in this context means: we have no commitment to preserving the meaning of them. If you use them, you do so at your own risk.

[BreyerW]

I also think that alternatives are smelly. I would prefer clean field and resolve conflicts in similar fashion to _ (in the past it was valid indentifier now it means discard if there is no valid indentifier otherwise it is a variable's name)

[dylanrafael05]

Other, prettier alternatives that could be considered:

backingfield or backing_field
autofield or auto_field
propfield or prop_field

The lack of a capital letter denoting the two words make collisions with identifiers in user code unlikely.