If a generic type is compared with null
(and only with null
), this causes the compiler to constrain the type both as nullable (which is ok) and as equatable.
Why the latter? It seems that just comparing with null
should be ok for types that are nullable, but don't support equality.
I know I can use Unchecked.equals
to get just the nullable constraint, just wondering if I'm missing some obvious reason why ((=) null)
needs an equatable argument.
The (=)
operator has type 'a -> 'a -> bool when 'a : equality
. Thus any use of the operator will constrain the type of its arguments to support equality. While it's true that this is technically an unnecessary restriction when you're comparing against the null literal, I think it's reasonable that the compiler just uses its normal inference procedure rather than treating it as a special case.
Note that you can always use obj.ReferenceEquals(x, null)
instead if the added constraints are objectionable.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With