Annotate ChangeTracking for nullability#24261
Conversation
1e94610 to
6f5b829
Compare
| /// <param name="value"> The property value if any. </param> | ||
| /// <returns> True if the property exists, otherwise false. </returns> | ||
| public virtual bool TryGetValue<TValue>([NotNull] string propertyName, out TValue value) | ||
| public virtual bool TryGetValue<TValue>([NotNull] string propertyName, out TValue? value) |
There was a problem hiding this comment.
But the value can be null even when true
There was a problem hiding this comment.
It's the same logic as with GetValue above (or with ReadShadowValue), i.e. whether the user calls TryGetValue<string> or TryGetValue<string?>`. We should make a global decision on that and apply everywhere.
There was a problem hiding this comment.
I think this is still left, since we made the decision to have GetValue return TValue and not TValue?.
563503a to
dba8ce0
Compare
dba8ce0 to
3cb3ea7
Compare
|
Hello @smitpatel! Because this pull request has the p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (
|
|
Apologies, while this PR appears ready to be merged, I've been configured to only merge when all checks have explicitly passed. The following integrations have not reported any progress on their checks and are blocking auto-merge:
These integrations are possibly never going to report a check, and unblocking auto-merge likely requires a human being to update my configuration to exempt these integrations from requiring a passing check. Give feedback on thisFrom the bot dev teamWe've tried to tune the bot such that it posts a comment like this only when auto-merge is blocked for exceptional, non-intuitive reasons. When the bot's auto-merge capability is properly configured, auto-merge should operate as you would intuitively expect and you should not see any spurious comments. Please reach out to us at fabricbotservices@microsoft.com to provide feedback if you believe you're seeing this comment appear spuriously. Please note that we usually are unable to update your bot configuration on your team's behalf, but we're happy to help you identify your bot admin. |
| if (value == null) | ||
| { | ||
| return null; | ||
| return default!; |
There was a problem hiding this comment.
Shouldn't this method return object[]? (and possibly banged at relevant call sites)? Though as long as it's correct, it's just a private function so no big deal.
small nit: I (now) usually use default! only in generic contexts. In reference type contexts like this one, I tend to use null! for more clarity.
There was a problem hiding this comment.
Long chain.
So basically this implements PrincipalKeyValueFactory<object[]> hence type becomes non-nullable. The reason for T = object[] because it is used as dependents map which uses dict underneath which cannot use nullable type as key. So while it is default! it shouldn't hit the code path here.
| if (index != -1) | ||
| { | ||
| ((HashSet<object>)_values[index])?.Remove(removedEntity); | ||
| ((HashSet<object>)_values[index]!)?.Remove(removedEntity); |
There was a problem hiding this comment.
If you want the runtime check, remove the bang; if we know it should never be null, remove the question mark.
|
|
||
| public T GetValue<T>(int index) | ||
| => IsEmpty ? default : _values.GetValue<T>(index); | ||
| => IsEmpty ? default! : _values.GetValue<T>(index); |
There was a problem hiding this comment.
This could be a case where it's more correct to return T?, since there's an additional Empty state. Is the user expected to know before calling this whether it's empty or not? If not, we probably want to force them to deal with the Empty state.
There was a problem hiding this comment.
The way whole T of GetValue flows, this shouldn't be invoked with non-null type if it can be empty. It is same as we returning T from other places, if you ask for wrong nullability it will throw exception. default! throws exception for us. @ajcvickers - Thoughts?
roji
left a comment
There was a problem hiding this comment.
Looks almost perfect, see comments below.
|
May bad, forgot to remove auto-merge, sorry. |
Part of #19007