3 ms·

Nullable vs. Nullable in C#

66 points by Bogdanp 1y ago

manuc66 1y ago
@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); } }
- Uvix 1y ago
  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.
- nick_ 1y ago
  I'm pretty sure you only need the OfType call. It filters out nulls already.
Dwedit 1y ago
Please remove the uppercase on the second "Nullable" in the headline.
jibal 1y ago
> 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.
dmatech 1y ago
This is why it's absolutely essential to always be aware of which types are value types in the .NET type system. Attempts by either users or the designers to conflate or unify them are ill-conceived. The nullability semantics could have been kept consistent if they went all the way back to the beginning of the CLR and did it that way, but this would have not been consistent with Java's JVM and type system (which they were trying to mimic). 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.
- bob1029 1y ago
  > 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.
  - dmatech 1y ago
    There's some really interesting stuff about how that works here: https://stackoverflow.com/a/56392846/7077511 https://stackoverflow.com/a/56392846/7077511
- tialaramex 1y ago
  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.
orthoxerox 1y ago
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 That's because the "type constraints are part of the signature of the method and there is no ambiguity" statement is wrong. They are not.
mrcsharp 1y ago
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,152b93d25e224365 https://source.dot.net/#System.Linq/System/Linq/Cast.cs,152b...
- LtWorf 1y ago
  If I was able to write a simple optimiser for relational algebra, I'm sure microsoft engineers can come up with something :D
- angrysaki 1y ago
  >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
  - mrcsharp 1y ago
    > 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 (!).
chrisoverzero 1y ago
> 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: 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 This is an allowable overload.
bazoom42 1y ago
Nullability on refererence types is boltet on in an ugly way in C#. Still a very valuable feature though.
gwbas1c 1y ago
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.

66 points by Bogdanp 1y ago

@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); } }

Uvix 1y ago
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.
nick_ 1y ago
I'm pretty sure you only need the OfType call. It filters out nulls already.

Dwedit 1y ago

Please remove the uppercase on the second "Nullable" in the headline.

jibal 1y ago

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

dmatech 1y ago

This is why it's absolutely essential to always be aware of which types are value types in the .NET type system. Attempts by either users or the designers to conflate or unify them are ill-conceived. The nullability semantics could have been kept consistent if they went all the way back to the beginning of the CLR and did it that way, but this would have not been consistent with Java's JVM and type system (which they were trying to mimic). 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.

bob1029 1y ago
> 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.
- dmatech 1y ago
  There's some really interesting stuff about how that works here: https://stackoverflow.com/a/56392846/7077511 https://stackoverflow.com/a/56392846/7077511
tialaramex 1y ago
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.

orthoxerox 1y ago

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 That's because the "type constraints are part of the signature of the method and there is no ambiguity" statement is wrong. They are not.

mrcsharp 1y ago

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,152b93d25e224365 https://source.dot.net/#System.Linq/System/Linq/Cast.cs,152b...

LtWorf 1y ago
If I was able to write a simple optimiser for relational algebra, I'm sure microsoft engineers can come up with something :D
angrysaki 1y ago
>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
- mrcsharp 1y ago
  > 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 (!).

chrisoverzero 1y ago

> 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: 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 This is an allowable overload.

bazoom42 1y ago

Nullability on refererence types is boltet on in an ugly way in C#. Still a very valuable feature though.

gwbas1c 1y ago

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.