Have bool and string implement ISpanParsable<T> #82836
Conversation
|
Note regarding the This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, to please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change. |
|
Tagging subscribers to this area: @dotnet/area-system-numerics |
|
Tagging subscribers to this area: @dotnet/area-system-runtime |
| return s.ToString(); | ||
| } | ||
|
|
||
| static bool ISpanParsable<string>.TryParse(ReadOnlySpan<char> s, IFormatProvider? provider, [MaybeNullWhen(returnValue: false)] out string result) |
There was a problem hiding this comment.
It doesn't really matter other than for consistency with other use, but whereas for a generic T we'll use [MaybeNullWhen(false)] out T, for a non-generic we'll use [NotNullWhen(true)] out string? .
There was a problem hiding this comment.
I went with this since its what the interface declaration was.
Is there a preference on updating to NotNullWhen(true) instead or is there any conflict in doing that given the usage via generics?
There was a problem hiding this comment.
Is there a preference on updating to NotNullWhen(true) instead
From a functionality perspective, it doesn't matter: [MaybeNullWhen(false)] out string and [NotNullWhen(true)] out string? are identical. We prefer the latter form in general because it more closely aligns with syntax of the language: the out is in fact nullable, hence the ?, and it's just that in certain circumstances we can use attributes to provide more information to the flow analysis, that we know even though it's nullable it won't be when the method returns true.
We can't, however, use [NotNullWhen(true)] out T, because the consumer might instantiate with a nullable T such that null is a valid value in the domain, such that NotNullWhen(true) would potentially be a lie. Hence, even though we prefer [NotNullWhen(true)], we use [MaybeNullWhen(false)] with unconstrained generics, since it ends up functionally being the same and is correct.
So, we do have a preference for [NotNullWhen(true)] when it's possible to use it. In this particular case, it's even less impactful because we're explicitly implementing the interface, so effectively no consumer will see the annotations here (outside of via reflection, which is really remote).
|
Build failures all look known and related to Mono or general osx timeouts: |
|
Awesome I've been missing these. 👍 |
jeffhandley
added
the
blog-candidate
ghost
locked as resolved and limited conversation to collaborators
This resolves #78842 and resolves #78523