question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

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

See original GitHub issue

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
    }
}

Issue Analytics

  • State:closed
  • Created 3 years ago
  • Comments:6 (6 by maintainers)

github_iconTop GitHub Comments

1reaction
jcouvcommented, Aug 26, 2020

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

0reactions
jcouvcommented, 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.

Read more comments on GitHub >

github_iconTop Results From Across the Web

Resolve nullable warnings
This set of warnings alerts you that you're dereferencing a variable whose null-state is maybe-null. These warnings are:.
Read more >
c# - How to suppress Possible Null Reference warnings
The use of an unconstrained generic type parameter T here means that this approach works for both reference types (such as string )...
Read more >
Containing Null with C# 8 Nullable References - praeclarum
This happens when you have declared that a field or a property requires a value (because its type doesn't have a ? ),...
Read more >
The Checker Framework Manual: Custom pluggable types ...
If a method can possibly throw an exception because its parameter is null, then that parameter's type should be @NonNull, which guarantees ...
Read more >
Using null type annotations
A type variable corresponding to a type parameter specified as @Nullable denotes a type that is known to be nullable. class C2<@Nullable T2...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found