-
Notifications
You must be signed in to change notification settings - Fork 5.3k
Remove TKey : notnull constraint from IDictionary<TKey, TValue>
#793
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
Conversation
The interface explicitly documents that some implementations may choose to support null keys.
safern
left a comment
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.
Yes, we should make the same change for IReadOnlyDictionary. Good catch. What "others"? |
I don’t think there are others. |
|
Actually I found some extension methos on https://github.com/dotnet/runtime/blob/master/src/libraries/System.Collections/ref/System.Collections.cs#L48 Those are all I could find. |
|
Thanks. I searched as well and pushed an update. |
| return dictionary.GetValueOrDefault(key, default); | ||
| } | ||
|
|
||
| [return: MaybeNull] |
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.
Interesting. This needs to be MaybeNullIfNull("defaultValue"), but that doesn't exist.
Context: dotnet/java-interop@01d0684 Annotates all API levels of `Mono.Android.dll` with [C#8 Nullable Reference Type][0] (NRT) annotations, pulled directly from the Java `.jar` files. Additionally, our hand written code has been audited and updated to include NRT annotations. ~~ Notes ~~ There are 8 new warnings caused by this change of the form: Android.Runtime/JavaDictionary.cs(655,24): warning CS8714: The type 'K' cannot be used as type parameter 'TKey' in the generic type or method 'IDictionary<TKey, TValue>'. Nullability of type argument 'K' doesn't match 'notnull' constraint. This is due to the BCL being improperly annotated. The change has since been reverted, but it has not made it into various distribution packs: dotnet/runtime#793 There are a considerable number of warnings (~400) caused by mismatched annotations when members are overridden, such as: CS8610: Nullability of reference types in type of parameter 'baz' doesn't match overridden member. While it may be desirable to fix these, it is a non-trivial job that will be prioritized separately. In the mean time, this set of warnings has been disabled: <NoWarn>8609;8610;8614;8617;8613;8764;8765;8766;8767</NoWarn> Finally, when `$(AndroidGenerateJniMarshalMethods)`=True and `jnimarshalmethod-gen.exe` is executed, the resulting app was crashing because `MagicRegistrationMap.CallRegisterMethodByIndex()` had a parameter change from `int` to `int?`. Fix this by calling `Nullable<int>.GetValueOrDefault()` with the `switch`. `MonoDroidMarkStep.UpdateRegistrationSwitch()` now emits IL like: .method private hidebysig static bool CallRegisterMethodByIndex([Java.Interop]Java.Interop.JniNativeMethodRegistrationArguments arguments, [mscorlib]System.Nullable`1<int32> typeIdx) cil managed { // Code size 9285 (0x2445) .maxstack 2 .locals init ([mscorlib]System.Nullable`1<int32> V_0) IL_0000: ldarg.1 IL_0001: stloc.0 IL_0002: ldloca.s V_0 IL_0004: call instance !0 [mscorlib]System.Nullable`1<int32>::GetValueOrDefault() IL_0009: switch ( … Co-authored-by: Radek Doulik <[email protected]> [0]: https://docs.microsoft.com/en-us/dotnet/csharp/nullable-references
Context: dotnet/java-interop@01d0684 Annotates all API levels of `Mono.Android.dll` with [C#8 Nullable Reference Type][0] (NRT) annotations, pulled directly from the Java `.jar` files. Additionally, our hand written code has been audited and updated to include NRT annotations. ~~ Notes ~~ There are 8 new warnings caused by this change of the form: Android.Runtime/JavaDictionary.cs(655,24): warning CS8714: The type 'K' cannot be used as type parameter 'TKey' in the generic type or method 'IDictionary<TKey, TValue>'. Nullability of type argument 'K' doesn't match 'notnull' constraint. This is due to the BCL being improperly annotated. The change has since been reverted, but it has not made it into various distribution packs: dotnet/runtime#793 There are a considerable number of warnings (~400) caused by mismatched annotations when members are overridden, such as: CS8610: Nullability of reference types in type of parameter 'baz' doesn't match overridden member. While it may be desirable to fix these, it is a non-trivial job that will be prioritized separately. In the mean time, this set of warnings has been disabled: <NoWarn>8609;8610;8614;8617;8613;8764;8765;8766;8767</NoWarn> Finally, when `$(AndroidGenerateJniMarshalMethods)`=True and `jnimarshalmethod-gen.exe` is executed, the resulting app was crashing because `MagicRegistrationMap.CallRegisterMethodByIndex()` had a parameter change from `int` to `int?`. Fix this by calling `Nullable<int>.GetValueOrDefault()` with the `switch`. `MonoDroidMarkStep.UpdateRegistrationSwitch()` now emits IL like: .method private hidebysig static bool CallRegisterMethodByIndex([Java.Interop]Java.Interop.JniNativeMethodRegistrationArguments arguments, [mscorlib]System.Nullable`1<int32> typeIdx) cil managed { // Code size 9285 (0x2445) .maxstack 2 .locals init ([mscorlib]System.Nullable`1<int32> V_0) IL_0000: ldarg.1 IL_0001: stloc.0 IL_0002: ldloca.s V_0 IL_0004: call instance !0 [mscorlib]System.Nullable`1<int32>::GetValueOrDefault() IL_0009: switch ( … Co-authored-by: Radek Doulik <[email protected]> [0]: https://docs.microsoft.com/en-us/dotnet/csharp/nullable-references
The interface explicitly documents that some implementations may choose to support null keys.
Fixes https://github.com/dotnet/corefx/issues/42386
cc: @buyaa-n, @safern, @sharwell