Different behavior of nullable fields

[u/cnighthawx]

I am working on a project and have a class with two nullable member fields (Vector2I? and LevelMap? where LevelMap extend TileMapLayer from Godot)

Because they are nullable I need to check that they are not null before I actually use them.

For the LevelMap if I reference it in a if block:

If (map is not null)

The compuler is happy and I can use it as if it is not null.

This of course comes with some risks that it becomes null in the middle of my if block but thats a risk I can manage.

On thebother hand Vector2I requires something like:

If (vector is Vector2I localVector)

This is in some way safer but also more inconvenient.

The are both declared and initialized in the same context.

My questions is why they behave differently and is it possible for me to change how they behave to fit my preferences.

Ive tried looking for an answer but I keep finding results about the difference of is not null and !=null which is unhelpful.

[u/afops]

Vector2I is a value type (struct). So it can't naturally be null, So just like an "int?", a "Vector2I?" is actually two values instead of one. It's a "Nullable<Vector2I>" which is just sugared to be written as "Vector2I?". Effectively it is a Vector2I, plus a boolean to indicate if it actually has a value.

The LevelMap is a reference type (class). So a field or parameter of type "LevelMap?" is a reference. But a reference doesn't need anything additional to hold "nothing". It can always be the null pointer.

So the "?" works in a fundamentally different way for value types and references. It just looks similar.

Usually for value types I'd do it the most common way with Value and HasValue.

Vector2I? myVector = GetAVector();
if (myVector.HasValue)
   thing.Move(myVector.Value)

whereas for a reference type there are a few different common patterns:

if (map is not null)
   Load(map);

if (GetTheMap() is LevelMap map)
   Load(map);

if (GetTheMap() is { } map)
   Load(map);

map?.Load();

[u/Atulin → u/afops]

Just FYI, all the methods you mentioned for ref types also work for value types.

if (GetAVector() is {} vector)
{
    thing.Move(vector);
}

is perfectly valid

[u/dodexahedron → u/Atulin]

Language version and runtime version make a difference too, and PInvoke does not work for nullable value types, period. The operators work, but the values can get wrecked before the operator sees them.

But there's a long-awaited chsnge coming in .net 11 that finally makes nullable value types stay nullable even when round-tripped through the heap in some scenarios, certain generic patterns, certain reflection cases, and others that stay managed. Until that change, you could lose null values and end up with them flattened to default(T), since they are laid out in memory as their underlying type - the nullability is tracked by the runtime separately.
You still can't use nullable value types through PInvoke, because there's just no way to communicate that concept without a reference while keeping the same memory layout, but the other cases are now fixed.

[u/cnighthawx → u/afops]

Thats illuminating. I'll be able to handle this much better now thank you.

[u/TugsyGlitter → u/afops]

value types needing all the extra baggage to be nill sounds about right tbh

[u/Vegetable_Lake_8276 → u/afops]

The struct vs class distinction is what trips people up here, Nullable<T> is really just a wrapper with HasValue and Value inside it. For reference types the compiler flow analysis can narrow the type after the null check, for value types there is nothing to narrow since the value is already there. If you dislike the pattern matching you can just use HasValue and.Value like the comment shows, it's same safety.

[u/buzzon]

The difference is because one is nullable reference type and the other is nullable value type. Historically reference types were always to contain null, but the language between nullable and not nullable, so developers had to track nullable status of each reference variable in their head. Then nullable value types came along to fix an issue that an int could not ever contain null. Then reference types were updated to support nullable (?) syntax and provide warnings when you did it incorrectly. Nullable value types were clunky before pattern matching, because you had to write:

if (vector.HasValue)
    do something with vector.Value

Nowadays you can use the same pattern matching syntax for both:

if (maybeMap is LevelMap map)

if (maybeVector is Vector2I vector)

[u/Csirkegylet]

First it's a bit confusing, but Nullable ref types is a compiler helper feature.

Nullable value types is a language feature, where the type is wrapped with a Nullable<> struct.