Skip to content

Switch to using field+auto-prop#76906

Merged
CyrusNajmabadi merged 37 commits intodotnet:mainfrom
CyrusNajmabadi:actuallyUseAutoProps
Jul 10, 2025
Merged

Switch to using field+auto-prop#76906
CyrusNajmabadi merged 37 commits intodotnet:mainfrom
CyrusNajmabadi:actuallyUseAutoProps

Conversation

@CyrusNajmabadi
Copy link
Contributor

No description provided.

@ghost ghost added Area-IDE untriaged Issues and PRs which have not yet been triaged by a lead labels Jan 24, 2025
@tmat
Copy link
Member

tmat commented Jan 24, 2025

I think the refactoring should move the property declaration to where the field declaration used to be if it's removing it. Or maybe we need to run follow up refactoring that groups data-backed members together.

Having (semi)auto-properties scattered across the type declaration makes it difficult to see what data the object holds onto, weather it has any mutable state, what the value of Order should be when you're adding another one with DataMember attribute, etc.

@RikkiGibson
Copy link
Member

I keep forgetting, only the diagnostics from the bootstrap build are going to be interesting here, when evaluating the new field nullability behavior.

@RikkiGibson
Copy link
Member

https://github.com/dotnet/roslyn/pull/76906/checks?check_run_id=39404423147

These appear to be the interesting diagnostics from the bootstrap build.

I thought that the _Framework build was going to be more relevant here, but, I think both Correctness_Bootstrap_Build jobs are equally useful here, it's actually a difference of whether the bootstrap compiler itself runs on framework or core, not a difference of which targets in Roslyn.sln get built.

@CyrusNajmabadi CyrusNajmabadi marked this pull request as ready for review July 10, 2025 07:02
@CyrusNajmabadi CyrusNajmabadi requested review from a team as code owners July 10, 2025 07:02
@CyrusNajmabadi
Copy link
Contributor Author

@JoeRobich ptal.

public ISymbol? Symbol { get; }
public CandidateReason CandidateReason { get; }
public ImmutableArray<ISymbol> CandidateSymbols => _candidateSymbols.NullToEmpty();
public ImmutableArray<ISymbol> CandidateSymbols => field.NullToEmpty();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I never realized there was a setter for this type of property.

public readonly ISymbol? Symbol = symbol;

public ImmutableArray<SymbolKindOrTypeKind> PossibleSymbolKinds => _possibleSymbolKinds.NullToEmpty();
public ImmutableArray<SymbolKindOrTypeKind> PossibleSymbolKinds { get => field.NullToEmpty(); } = possibleSymbolKinds;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know this PR didn't introduce it, but is there a quirk here that makes NullToEmpty() necessary?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is primarily making sure that if someone either passed default to the consturctor or just has a default instance of NameDeclarationInfo that PossibleSymbolKinds still always returns an empty array. It makes it so that teh entire domain you have to think about for PossibleSymbolKinds is non-defualt arrays (so real arrays of 0 to N length). It removes the null/default case as something to ever even have to eb concerned with.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Practically, we have good hygiene, and this is generally not a concern. But it is something that occasionally arises, and thse patterns help.

public ExportProvider ExportProvider { get; }

internal ServerCapabilities ServerCapabilities => _serverCapabilities ?? throw new InvalidOperationException("Initialize has not been called");
internal ServerCapabilities ServerCapabilities { get => field ?? throw new InvalidOperationException("Initialize has not been called"); private set; }
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like this so much. That it allows field to be nullable before it is initialized. I am thinking of all the places I have nullable fields that are only nullable because they aren't set in the constructor.

Copy link
Contributor Author

@CyrusNajmabadi CyrusNajmabadi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

a

public readonly ISymbol? Symbol = symbol;

public ImmutableArray<SymbolKindOrTypeKind> PossibleSymbolKinds => _possibleSymbolKinds.NullToEmpty();
public ImmutableArray<SymbolKindOrTypeKind> PossibleSymbolKinds { get => field.NullToEmpty(); } = possibleSymbolKinds;
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Practically, we have good hygiene, and this is generally not a concern. But it is something that occasionally arises, and thse patterns help.

@CyrusNajmabadi CyrusNajmabadi merged commit d3a88ce into dotnet:main Jul 10, 2025
25 checks passed
@CyrusNajmabadi CyrusNajmabadi deleted the actuallyUseAutoProps branch July 10, 2025 18:48
@dotnet-policy-service dotnet-policy-service bot added this to the Next milestone Jul 10, 2025
@RikkiGibson RikkiGibson modified the milestones: Next, 18.0 P1 Aug 19, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Area-IDE untriaged Issues and PRs which have not yet been triaged by a lead VSCode

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants