Why does .NET 8 warn me that my Reference type is possibly non-nullable?

[BrienKing]

I have a class

public class Foo
{
}

then I use it somewhere else...

public void DoStuff()
{
Foo myFoo = null;
}

Why is .Net 8 warning me about the assignment?

CS8600 - Converting null literal or possible null value to non-nullable type.

Foo is nullable by default is it not since it's a reference type?

This seems to add a lot of noise to my warnings that are unnecessary.

[stephentoub]

With nullable reference types, Foo is non-nullable, and Foo? is nullable.

[BrienKing]

I was under the impression that Reference Types were always nullable to begin with. It was the Value Types that were not.

[huoyaoyuan]

It was a C# feature back to C# 8. See https://learn.microsoft.com/en-us/dotnet/csharp/nullable-references.
The default project template enables the feature since .NET 6. There's nothing new in .NET 8.

[BrienKing]

That still doesn't answer my question though. Up until now I've been using .Net 4.8. Writing new app in .Net 8 Blazor and running into this. It seems very odd to me to give me a warning like this. Curious as to the rational behind it.

[svick]

@BrienKing The rationale is that nullability issues are a common source of bugs, so we need a way to differentiate nullable reference types from non-nullable reference types. And since nullability is assumed to be less common, non-nullable is the default.

[DrkWzrd]

If you use the question mark ? the warning disappears, because you made explicit to the compiler that YOU know that can be null (or is null), and the compiler helps you keeping track of the null state across the code showing it to you with intellisense (if it is clear, the compiler isn't magical). At the beginning it's annoying, but once you get used to, is a quick first-sight way to know if you should/must check for nullability when something like this is passed as parameter.

public static string? DoSomethingWithStuff(string base1, string? append)
{
    if(append is null) return null;
    return base1.EndsWith(append) ? "true" : "false";
    /// If people using this method is reasonable and cares about the warnings and that kind of things, 
    /// I don't need to check if base1
    /// parameter is nullable, because they receive a warning 
    /// if they try to put a null in base1 field when use this function.
    /// The same way, I warn to everybody that my function CAN return null 
    /// and should treat my function with diligence about it.

    /// If instead my method looks only like this
    return append.EndsWith(base1) ? "true: false";
    /// I will receive one warning saying me "hey, check if append is null, because it can be null".
}

It's a quick way to express a consensus about possible nullability of a reference type. Instead of state "this reference type variable can be null and we don't know unless we check it", it becomes "this reference type variable should not be (important should not) be null because the developer have stated explicitly that cannot be null (using the abscense of ?)".
The only caveat is it's a warning, not a compiler error.

[BrienKing]

Well, I've disabled this as it's just noise to me. I always assume a reference type can be null in my code and treat it appropriately.

[Clockwork-Muse]

@BrienKing - You generally still are supposed to place the checks at the public API surface, even with nullable reference types being enabled (Because the compiler/runtime doesn't exhaustively check, because of legacy code).

The benefit - besides being documentation for users - is that you can elide those checks in internal code, because it should have been sufficiently verified. Are you checking for null references in internal/private methods? Before each use? Because that's one of the primary burdens it's attempting to relieve.

The other benefit is for when you accidentally forget one or more - such as if you switch a type from being a struct to being a class, or similar

---

On a personal note, I would consider any library that deliberately turned the feature off and didn't mark things appropriately to be "less reliable". If possible, I would avoid such a library; failing that, I would write a wrapper interface with the appropriate typing. Using NRT is part of being a "good citizen" in the ecosystem.

[TonyValenti]

The whole reason ? exists is so that you can clearly indicate whether you expect null or not.

If you've made the decision that you will always expect a reference to be null and you're silencing that warning, you're taking a position that is at odds which the philosophy of the folks that actually build the language you're using.

I can't speak for other orgs, but at least in the company I work for, that would eliminate your prospects for advancement.

[BrienKing]

Personally, I think they got it backwards. They should have had something to the effect of "This reference type will not be null". Having to add the ? to a reference type, that by it's very definition "may be null", to tell the compiler that my reference type "may be null", is odd.

It's a moot point as they won't be changing it and I already treat all reference types as if they could be null, so this doesn't help me, it just adds a bunch of noise in my warnings list unless I turn the feature off.

[huoyaoyuan]

The original proposal actually designs two syntaxs, T? for may be null and T! for must not be null.

[En3Tho]

@BrienKing No, they got it right because most of the time you operate with non-null values. And the reason is that null is... useless. You can't do anything meaningful with it, just indicate an absence of a value.

The modern C# helps you to not think about whether this might be null or not. You just know. This saves you from a constant feeling of "what if I don't check this?". Saves you from an unnecessary null checks all over the place that just literally litter your code.

It makes your api and types much better defined as you clearly state what is designed to be possibly absent and what is not.

For example, let's imagine a User type which should always have an "Id" which is represented by string. If it doesn't then the type's constructor and buggy or the value was created in an hacky unsafe say.

It makes perfect sense to annotate "Id" as non-nullable and always treat it as such.

But other properties, like maybe a "DisplayName" are not required to be present and may be null. In this case you annotate it as "string?".

This makes it much easier to reason about your types and apis. It makes it much easier to consume other people libraries because you know what is designed to be nullable and what is not.

I understand you might feel frustrated with it because you already got a bunch of code working without these annotations. It's up to you whether to convert that code to NRT or disable it. It is certainly a huge amount of work to migrate existing code to use this feature.

But I strongly suggest you use this feature in your new projects or libraries. You will appreciate it for sure.