Modernize pipe message models' nullability declarations. #321
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…del properties, as the method's reliance on the `new()` constraint is incompatible with applying `required`. This entire change was performed by an automated refactoring.
… their intended use is to be fully populated upon construction and never changed.
…e set either in constructors or object initializer, instead of using the older fallback assertion `= default!`, allowing the compiler to vet that assertion.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When nullable reference types were first enabled, the
PipeMessagemessage types presented an annoyance. Their setters were naturally public{ get; set; }, though we wanted to declare the property types as non-null. Careful tracing of code paths confirmed that by the time they would be inspected, they really would be non-null. Having to mark them with?would have needlessly spread unrealistic warnings to their usages, so instead we marked them all with the "confident assertion"{ get; set; } = default!.Since then C# has added two useful keywords which better help express and enforce the intention of these "serializable property bucket" types. Here we apply both of them:
initas an alternative toset, communicating that they are intended to be populated during construction/initialization.requiredas an alternative to= default!, communicating that there is no need for a weak nullability assertion as the value will verifiably be assigned non-null upon initialization.