Probably the fix belongs in SymbolDisplay?

Just be curious: what will be displayed in quick info for such backing field? int C.field or just int field?

Also:

Just be curious: what will be displayed in quick info for such backing field? int C.field or just int field?

I think int C.P.field would be best for symbol display. The property is a logical container for the field. @cston in case you have any additional thoughts here.

Doing a quick check for what additional behaviors need to be specified, using property accessors (e.g. int C.P.get) as a starting point for the way the field name is displayed.

• https://github.com/dotnet/roslyn/blob/main/src/Compilers/Core/Portable/SymbolDisplay/SymbolDisplayMemberOptions.cs
• https://github.com/dotnet/roslyn/blob/main/src/Compilers/Core/Portable/SymbolDisplay/SymbolDisplayMiscellaneousOptions.cs
• https://github.com/dotnet/roslyn/blob/main/src/Compilers/CSharp/Test/Symbol/SymbolDisplay/SymbolDisplayTests.cs

I am not seeing any options or tests which apply customization of how a property accessor name is displayed. I don't think we should offer any option to, for example, omit the field name component from symbol display. But, let's bring the question up with API review.

I am also thinking that the symbol display behavior should be independent of LangVersion. I do not think that SymbolDisplayVisitor.Members has any existing cases of language version affecting the way symbols are displayed.

I'd prefer just naming the property. Is there a reason that would not be suitable?

That would be confusing, because the tracked-null state of field and P may differ.

Agree with @jnm2. The backing field is a distinct symbol, and when using the backing field, it is helpful to be clear that is what you are using and not the containing property.

Ah ok. int X.field makes sense. Similar to int X.set.

@RikkiGibson why is this marked as "api-ready-for-review". I don't see any API changes in the comments here.

It was suggested in offline conversation with @cston that we should run this scenario by API review to decide if we want to introduce any symbol display options related to this feature.

I think an email discussion with the api review alias, or with the owner of the api (@AlekseyTs and myself) is the appropriate first step here, rather than bringing it to the entire api review meeting.

We discussed on the internal mailing list and got several folks on board with the suggested design.

• Display of a backing field symbol will suffix '.field' onto the display of the containing property. This is similar to the way property accessors are handled by suffixing '.get', for example.
• This only applies when the field itself is used, which generally only occurs within the accessors of the containing property.
• Therefore display of an example symbol like 'field' in 'int Prop { get => field; }' will result in 'int ContainingType.Prop.field' when the appropriate options are used.
• No new options are provided for customizing the display. Existing options which affect things like type name and member name qualification continue to be respected.
• This will apply to all backing field symbols, including those associated with "classic" auto properties. (Such symbols have generally not been displayed in IDE scenarios to date.)
• Symbol display options which indicate the metadata name should be displayed, should also apply here (e.g. causing the field's unspeakable metadata name to be shown as it is today.)

@RikkiGibson Quick question: is the type in string C.P.field going to have the field's nullability annotation?

For now, I am expecting the field to have, and show, the same type and nullable annotation as the containing property.

If we move forward with null-resilient getters, I am not sure yet whether the inferred nullability should surface in the symbol model. Basically, it seems risky to make it so accessing the TypeWithAnnotations of a symbol (or just the Type in public symbol API), causes a get accessor to be bound and flow analyzed. It could make the access unexpectedly costly, and could introduce cycles which are difficult to stamp out.

Though, FWIW, we know that work is already done and being surfaced in the Quick Info case.

It didn't occur to me that changing this behavior for all backing fields would break a billion test baselines, but I will still do it.