-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clarify null name for IOptions related types #10038
Conversation
I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label. |
1 similar comment
I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label. |
Learn Build status updates of commit cdd065e: ✅ Validation status: passed
For more details, please refer to the build report. For any questions, please:
|
Tagging subscribers to this area: @dotnet/area-extensions-options |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kevincathcart-cas thanks for helping with the doc clarification. LGTM.
Should we add something telling Microsoft.Extensions.Options.Options.DefaultName
is empty string too? This may help users to understand what name value they will get.
CC @gewarren
Co-authored-by: Genevieve Warren <24882762+gewarren@users.noreply.github.com>
Learn Build status updates of commit 15f926f: ✅ Validation status: passed
For more details, please refer to the build report. For any questions, please:
|
Summary
Fixes some really poor wording related to passing null to Get(string? name) methods of IOptions related types.
Was:
But that makes no sense. DefaultName is
public static readonly string DefaultName = string.Empty;
and cannot be null. The actual intention is to document that these types use the value ofDefaultName
if null is passed.Now:
That is accurate and contractual. Unnamed options use
DefaultName
for their name, as documented in many places in these docs, and passing null here is explicitly requesting that the unnamed version of the option is returned, which happens by usingDefaultName
. Any alternate implementation of the interfaces in question that distinguished betweennull
andDefaultName
, would be non-conforming and incompatible since apps can freely choose to passnull
orDefaultName
, and don't expect any difference between the two.