-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
Consider representing nullable flow state as: MaybeNull, NotNull, or T #38638
Comments
FYI for @jasonmalinowski |
Even if we just add the third state, without adding a corresponding type/annotation for locals, some scenarios would be improved. #nullable enable
using System;
using System.Diagnostics.CodeAnalysis;
public class C<T> {
[MaybeNull] T value;
public void M() {
if (value is null)
return;
}
} |
This example just started giving me warnings in VS 16.4 Preview 2 [return: MaybeNull]
public static TValue GetValueOrDefault<TKey, TValue>(this IDictionary<TKey, TValue> dic, TKey key, TValue defaultValue = default) where TKey : notnull =>
dic.TryGetValue(key, out var value) ? value : defaultValue; Results in warning CS8717: A member returning a [MaybeNull] value introduces a null value when 'TValue' is a non-nullable reference type Would this allow the |
CS8717 feels subpar to me. The warning should follow the (mis)usage, not the declaration. As it stands, CS8717 only shows up on valid (even ideal) code. void M<T>()
{
var x = new Dictionary<int, T>();
// CS8717 A member returning a [MaybeNull] value introduces a null value when 'TResult' is a
// non-nullable reference type.
// ↓
if (x.TryGetValue(42, out var someValue))
{
}
} |
FYI, this is super unpleasant. I honestly don't know how to write code in some cases that is actually NRT correct. I thought MaybeNull was intended for this, but @jcouv informs me that for the actual uninstantiated cases (i.e. while you're writing generic code), you're just SOL here :-/ |
This suppresses: A member returning a [MaybeNull] value introduces a null value when 'T' is a non-nullable reference type, which is unavoidable with compiler work to track state more accurately. This is being tracked by: dotnet/roslyn#38638
… which has the fix for dotnet/roslyn#38638
Consider adding a distinct nullable flow state, T, to allow distinguishing "maybe null when the type allows null" from "maybe null even when type disallows null".
The text was updated successfully, but these errors were encountered: