Skip to content
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

No warning reported for assignment or explicit cast of possibly null value of unconstrained type parameter type #46044

Closed
cston opened this issue Jul 16, 2020 · 6 comments · Fixed by #48803

Comments

@cston
Copy link
Member

cston commented Jul 16, 2020

No warnings are reported for the assignment to t in F1() or the explicit cast (T) in F2().

#nullable enable

class Program
{
    static T F1<T>()
    {
        T t = default; // no warning
        return t;      // warning: possible null return
    }

    static T F2<T>(object? o)
    {
        T t = (T)o; // no warning
        return t;      // warning: possible null return
    }
}

For type parameters with constraints (or explicit types), the compiler reports warning CS8600: Converting null literal or possible null value to non-nullable type for those cases. The warning is not a safety warning because the compiler still tracks the "maybe default" state of the value and reports actual safety warnings when the values are used, as in the warnings reported for return t; above. But it is a difference in behavior between unconstrained type parameters and other types.

The reason the compiler does not report warnings for unconstrained type parameters is because in C#8 there is no syntax to specify the nullable version of the type parameter so any warning would require a ! suppression.

Post C#8, unconstrained type parameters can be annotated, so the code above could be replaced with the following. Given that, should the compiler report CS8600 for the cases above?

#nullable enable

class Program
{
    static T F1<T>()
    {
        T? t = default; // ok
        return t;       // warning: possible null return
    }

    static T F2<T>(object? o)
    {
        T? t = (T?)o; // ok
        return t;     // warning: possible null return
    }
}
@cston
Copy link
Member Author

cston commented Jul 24, 2020

Closing as by design. Changing this now would be a breaking change.

@cston cston closed this as completed Jul 24, 2020
@jcouv jcouv added this to Language in Compiler: Julien's umbrellas Jul 25, 2020
@jcouv
Copy link
Member

jcouv commented Jul 27, 2020

Re-opening following LDM 7/27/2020 (let's re-introduce this warning behind a warning wave, using a distinct diagnostic ID).

@jcouv jcouv reopened this Jul 27, 2020
@RikkiGibson
Copy link
Contributor

Do we aspire to get this warning into .NET 5?

@jcouv
Copy link
Member

jcouv commented Aug 26, 2020

@RikkiGibson Yes, although it's probably not a blocker (we could do it in a following warning wave)

@cston
Copy link
Member Author

cston commented Aug 27, 2020

From offline discussion, if possible we should use the existing warning, CS8600, and report warnings for these cases when using /langversion:9, rather than using a new warning id and a warning wave.

@cston cston modified the milestones: 16.8, Compiler.Next Aug 27, 2020
@jcouv
Copy link
Member

jcouv commented Aug 27, 2020

If/when we decide to move ahead with investigation (what's the impact on roslyn/VS/runtime), we should remember to let LDM know.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment