Nullable vs. Nullable in C#(einarwh.no)
einarwh.no
Nullable vs. Nullable in C#
https://einarwh.no/blog/2025/08/25/nullable-vs-nullable/
26 comments
The class/struct approach predates C#.
For example in Eiffel by default they are references, but can also be turned into value types if the are blesses ones like numeric types, or if the developer tags them as expanded classes, either at definition or declaration type.
Delphi makes the distinction between classical object, and records from Object Pascal (both value based, and explicit pointers are required), or class types, heap only.
Modula-3 classes and records also follow similar approach, OBJECT follows the same semantic model of REF RECORDS.
For more modern examples, also D and Swift follow this approach.
And plenty of other examples for anyone wanting to dive into SIGPLAN.
For example in Eiffel by default they are references, but can also be turned into value types if the are blesses ones like numeric types, or if the developer tags them as expanded classes, either at definition or declaration type.
Delphi makes the distinction between classical object, and records from Object Pascal (both value based, and explicit pointers are required), or class types, heap only.
Modula-3 classes and records also follow similar approach, OBJECT follows the same semantic model of REF RECORDS.
For more modern examples, also D and Swift follow this approach.
And plenty of other examples for anyone wanting to dive into SIGPLAN.
It is in hindsight unfortunate that this idea didn't get into the CLR itself.
The blog post doesn't mention this, but whereas if I say my function only takes this 32-bit signed integer value type, a VB.NET caller can't hand it "null" because that's not a 32-bit signed integer - if instead I say it takes string (not the nullable string?) too bad, the VB.NET caller can just pass null anyway because in the CLR there's no distinction.
You're actually expected (if you provide public surface) to write a null test, in your C# code which explicitly says in the function signature that this mustn't be null, otherwise it might blow up at runtime because the CLR doesn't care.
The blog post doesn't mention this, but whereas if I say my function only takes this 32-bit signed integer value type, a VB.NET caller can't hand it "null" because that's not a 32-bit signed integer - if instead I say it takes string (not the nullable string?) too bad, the VB.NET caller can just pass null anyway because in the CLR there's no distinction.
You're actually expected (if you provide public surface) to write a null test, in your C# code which explicitly says in the function signature that this mustn't be null, otherwise it might blow up at runtime because the CLR doesn't care.
Nullable types came into C# during the .NET Framework days, back when the team had very high bar to ever add features that would change the runtime as OS component.
Hence why async/await is such a mess of IL bytecode, as it was implemented in userspace so to say.
Only with .NET Core, they followed other languages in not tying the runtime to the OS, a lesson that Google also had to learn (ART is updatable via PlayStore since Android 12).
Hence why async/await is such a mess of IL bytecode, as it was implemented in userspace so to say.
Only with .NET Core, they followed other languages in not tying the runtime to the OS, a lesson that Google also had to learn (ART is updatable via PlayStore since Android 12).
> That said, we already have value types like System.Int32 which inherit from System.ValueType (an abstract type) which inherits from System.Object (a non-abstract reference type), so things are already a bit weird.
But it all works, right? The runtime can do anything it wants to with the IL. The handling of Vector<T> is a good example of this - Locating arbitrary types/namespaces and emitting special instructions based upon the current machine's capabilities. Normalizing value vs reference semantics would be a tiny drop in this bucket.
But it all works, right? The runtime can do anything it wants to with the IL. The handling of Vector<T> is a good example of this - Locating arbitrary types/namespaces and emitting special instructions based upon the current machine's capabilities. Normalizing value vs reference semantics would be a tiny drop in this bucket.
There's some really interesting stuff about how that works here:
https://stackoverflow.com/a/56392846/7077511
https://stackoverflow.com/a/56392846/7077511
I wonder if anybody has tried inheriting from System.ValueType or System.Object...I need to fire up an IDE and see what kind of virtuals and abstracts are exposed by doing so. If even possible.
It seems like an inheritance hierarchy build upon abstract classes that provide no usable interface just means "hey we need this inheritance for...reasons... cause its legacy!" on the one hand, and "we can rip all this useless ** out" on the other hand.
It seems like an inheritance hierarchy build upon abstract classes that provide no usable interface just means "hey we need this inheritance for...reasons... cause its legacy!" on the one hand, and "we can rip all this useless ** out" on the other hand.
[deleted]
As I understand, all types implicitly inherit from Object in C#. That's where the `ToString` and hashcode overrides come from.
Offhand, I'd guess that explicitly inheriting from Object would either do nothing or fail to compile depending on where in the type hierarchy you are.
Similarly, all structs implicitly inherit from ValueType. That's what structs are in C#.
Offhand, I'd guess that explicitly inheriting from Object would either do nothing or fail to compile depending on where in the type hierarchy you are.
Similarly, all structs implicitly inherit from ValueType. That's what structs are in C#.
Truthfully I think the language lost something critically important when we went gung-ho on purging ourselves of the EVILS! of nullable types.
Back in the Paleolithic, the only way to get a nullable value type was to extremely explicitly box it into a Nullable<T>. The distinction between value and reference types was crystal clear and unmistakable. Boxing values required an active and deliberate decision.
Now I guess we just box everything because null checks are hard or something.
Back in the Paleolithic, the only way to get a nullable value type was to extremely explicitly box it into a Nullable<T>. The distinction between value and reference types was crystal clear and unmistakable. Boxing values required an active and deliberate decision.
Now I guess we just box everything because null checks are hard or something.
C# doesn't box value types and can be treated like an object semantically for things like generics.
IMO, we should just do away with nullability and use the optional/maybe approach as wrappers for potential values. Null shouldn't really exist ideally, especially in OO because it is a unit value and also the parent value for all objects. I appreciate nullability being introduced but it causes a fork in types by two branches at the top of the hierarchy in most cases and more conceptually just associates these optionals with this flawed concept.
IMO, we should just do away with nullability and use the optional/maybe approach as wrappers for potential values. Null shouldn't really exist ideally, especially in OO because it is a unit value and also the parent value for all objects. I appreciate nullability being introduced but it causes a fork in types by two branches at the top of the hierarchy in most cases and more conceptually just associates these optionals with this flawed concept.
> Luckily, since type constraints are part of the signature of the method and there is no ambiguity, I am allowed to make this overload.
This isn’t the case. It’s allowed because the question-mark syntax means two different things in value- and reference-type contexts. The signatures really look like this:
This isn’t the case. It’s allowed because the question-mark syntax means two different things in value- and reference-type contexts. The signatures really look like this:
public static IEnumerable<TR> SelectNotNull<T, TR>(
this IEnumerable<T> source,
Func<T, TR> fn)
where TR : class // …and the nullability of TR is tracked by the compiler
public static IEnumerable<TR> SelectNotNull<T, TR>(
this IEnumerable<T> source,
Func<T, Nullable<TR>> fn)
where TR : struct
> to denote two completely separate concepts
No, same concept ... you're making a mistake that some call "implementation on the brain". That they're the same concept is why you're able to specify a common operation, SelectNotNull. That you had to provide an explicit type constraint that a compiler should be able to infer doesn't change that.
No, same concept ... you're making a mistake that some call "implementation on the brain". That they're the same concept is why you're able to specify a common operation, SelectNotNull. That you had to provide an explicit type constraint that a compiler should be able to infer doesn't change that.
Please remove the uppercase on the second "Nullable" in the headline.
As a side note: please avoid, as much as possible, putting `.Select(..)` before `.Where(..)`. You are wasting CPU cycles and memory space by forcing LINQ to map all the items and then filtering on the mapped value.
In most situations, you should be able to filter on the source enumerable before mapping making the whole thing more efficient.
Additionally, that `.Cast<TR>(..)` at the end should have been a dead giveaway that you are going down the wrong path here. You are incurring even more CPU and Memory costs as the `.Cast<TR>(..)` call will now iterate through all the items needlessly.[1]
Also, the design of this this method doesn't seem to make much difference to me anyways:
``` var strs = source.SelectNotNull(it => it); ```
vs
``` var strs = source.Where(it => it != null); ```
A lot of other LINQ extension methods allow you to pass in a predicate expression that will be executed on the source enumerable:
``` var str = source.First(it => it != null); ```
[1] https://source.dot.net/#System.Linq/System/Linq/Cast.cs,152b...
In most situations, you should be able to filter on the source enumerable before mapping making the whole thing more efficient.
Additionally, that `.Cast<TR>(..)` at the end should have been a dead giveaway that you are going down the wrong path here. You are incurring even more CPU and Memory costs as the `.Cast<TR>(..)` call will now iterate through all the items needlessly.[1]
Also, the design of this this method doesn't seem to make much difference to me anyways:
``` var strs = source.SelectNotNull(it => it); ```
vs
``` var strs = source.Where(it => it != null); ```
A lot of other LINQ extension methods allow you to pass in a predicate expression that will be executed on the source enumerable:
``` var str = source.First(it => it != null); ```
[1] https://source.dot.net/#System.Linq/System/Linq/Cast.cs,152b...
If I was able to write a simple optimiser for relational algebra, I'm sure microsoft engineers can come up with something :D
>Also, the design of this this method doesn't seem to make much difference to me anyways:
``` var strs = source.SelectNotNull(it => it); ```
vs
``` var strs = source.Where(it => it != null); ```
Wouldn't the first be IEnumerable<TR> and the second be IEnumerable<TR?>
I imagine that's the main driver for creating SelectNotNull, so that you get the nonnullable type out of the Linq query
``` var strs = source.SelectNotNull(it => it); ```
vs
``` var strs = source.Where(it => it != null); ```
Wouldn't the first be IEnumerable<TR> and the second be IEnumerable<TR?>
I imagine that's the main driver for creating SelectNotNull, so that you get the nonnullable type out of the Linq query
> I imagine that's the main driver for creating SelectNotNull
Sure. And now we are fighting the compiler and in the process writing less efficient code.
The compiler gives us a way to deal with this situation. It is all about being absolutely clear with intentions. Yes, Where(..) in my example would return IEnumerable<TR?> but then in subsequent code I can tell the compiler that I know for a fact that TR? is actually TR by using the null forgiving operator (!).
Sure. And now we are fighting the compiler and in the process writing less efficient code.
The compiler gives us a way to deal with this situation. It is all about being absolutely clear with intentions. Yes, Where(..) in my example would return IEnumerable<TR?> but then in subsequent code I can tell the compiler that I know for a fact that TR? is actually TR by using the null forgiving operator (!).
>The compiler gives us a way to deal with this situation. It is all about being absolutely clear with intentions. Yes, Where(..) in my example would return IEnumerable<TR?> but then in subsequent code I can tell the compiler that I know for a fact that TR? is actually TR by using the null forgiving operator (!).
I guess that seems way less clear with intentions to me. If I have an array of potentially null types and I want to filter out the not nulls, I'd much rather have an operation that returns a T[] vs a T?[].
I should also note that I also have a "IEnumerable<T> WhereNotNull(IEnumerable<T>?)" function in my codebase, but I implemented it using a foreach/yield which doesn't suffer from the extra Cast<>()
I guess that seems way less clear with intentions to me. If I have an array of potentially null types and I want to filter out the not nulls, I'd much rather have an operation that returns a T[] vs a T?[].
I should also note that I also have a "IEnumerable<T> WhereNotNull(IEnumerable<T>?)" function in my codebase, but I implemented it using a foreach/yield which doesn't suffer from the extra Cast<>()
I actually use OfType<TR> to remove null elements as suggested by the doc. https://learn.microsoft.com/en-us/dotnet/api/system.linq.enu... Performance-wise, where is this situated?
@Bogdanp maybe this is another way to express it:
public static class EnumerableExtensions {
public static IEnumerable<TR> SelectNotNull<T, TR>( this IEnumerable<T> source, Func<T, TR?> fn) where TR : class { return source.Select(fn) .Where(it => it != null) .OfType<T>(); }
public static IEnumerable<TR> SelectNotNull<T, TR>( this IEnumerable<T> source, Func<T, TR?> fn) where TR : struct { return source.Select(fn) .Where(it => it != null) .Select(item => item.Value); } }
public static class EnumerableExtensions {
public static IEnumerable<TR> SelectNotNull<T, TR>( this IEnumerable<T> source, Func<T, TR?> fn) where TR : class { return source.Select(fn) .Where(it => it != null) .OfType<T>(); }
public static IEnumerable<TR> SelectNotNull<T, TR>( this IEnumerable<T> source, Func<T, TR?> fn) where TR : struct { return source.Select(fn) .Where(it => it != null) .Select(item => item.Value); } }
Both look like they’ll work. For the struct case I think yours is better. For the class case I think using Cast() like the original instead of OfType() makes more sense - you don’t need to filter out other types from the enumerable, so cast once instead of casting then performing a useless check on the result.
I'm pretty sure you only need the OfType call. It filters out nulls already.
Nullability on refererence types is boltet on in an ugly way in C#. Still a very valuable feature though.
OP's code only works because the method goes from T? to T. If it accepted T and returned T?, he would've gotten an error like this:
CS0111: Type 'Utils' already defines a member called 'Foo' with the same parameter types
Uhm: There is the OfType method that is generally used to filter an IEnumerable<T?> to IEnumerable<T>. It doesn't care about reference vs value types, because it doesn't compare to null. Instead it checks the type of each element.
Why? If you have an value, foo, that's declared "int?", (foo is int) evaluates to if there is a value present, and false if there is no value present. The same thing happens if foo is declared as string?.
BTW: I checked if the overload can be avoided by using the "default" keyword. It can't.
Why? If you have an value, foo, that's declared "int?", (foo is int) evaluates to if there is a value present, and false if there is no value present. The same thing happens if foo is declared as string?.
BTW: I checked if the overload can be avoided by using the "default" keyword. It can't.
That said, we already have value types like System.Int32 which inherit from System.ValueType (an abstract type) which inherits from System.Object (a non-abstract reference type), so things are already a bit weird.