I have two variables of type int? (or Nullable<int> if you will). I wanted to do a greater-than-or-equal (>=) comparison on the two variables but as it turns out, this returns false if both variables are null, while obviously the == operator returns true.
Can someone explain to me why that is logical because the semantical definition of the >= operator contains the word "or"?
There was a huge debate about this oddity when the feature was originally designed back in C# 2.0. The problem is that C# users are completely used to this being meaningful:
if(someReference == null)
When extending equality to nullable value types, you have the following choices.
Nullable equality is truly lifted. If one or both of the operands is null then the result is neither true, nor false, but null. In this case you can either:
a) Make it illegal to have a nullable value type equality in an if statement, because the if statement needs a bool, not a nullable bool. Instead, require everyone to use HasValue if they want to compare to null. This is verbose and irritating.
b) Automatically convert null to false. The downside of this is that x==null returns false if x is null, which is confusing and works against people's understanding of null comparisons with reference types.
Nullable equality is not lifted. Nullable equality is either true or false, and comparison to null is a null check. This makes nullable equality inconsistent with nullable inequality.
None of these choices is obviously correct; they all have pros and cons. VBScript chooses 1b, for example. After much debate the C# design team chose #2.
<, <=, =>, or > when one of the operands is null. In C#, the answer is return false. In the Scala/Java String class, the answer is to throw a NullPointerException. –
Filtrate >=, <=, >, or < operator and one or both operands is null, throw a NullReferenceException . This places a burden on the programmer similar to 1a. I consider this and 1a to be ivory tower approaches: they feel more "correct," but they ignore the practical consideration that people have to actually use them. –
Tackett NullReferenceException solution is that you save typing if you "know" that they are not null. Though why you would "know" that but still be using a nullable is a mystery. Anyhow, I acknowledge that this is a bad idea; it's kind of like 1a except if you try to treat nullable as a regular number it will wait until runtime to inform you of your error instead of compile time. –
Tackett if(someReference == null) being allowed, but it shouldn't be. It might be a convenient fudge, but then leads to problems like this resulting in nonsense answers that are internally contradictory. This seems to be the antithesis of the Pit Of Success. –
Giacobo Because Equality is defined separately from Comparability.
You can test x == null but x > null is meaningless. In C# it will always be false.
>= is simply not defined. –
Firebox Another way of describing '>=' is: Not Less Than. No mention of equals. As soon as one of the operands in a non-equality test is Null, the result is unknown as well (is null). However if you want to know if both operands are Null, then Null == Null is a reasonable test (should result in true). Getting rid of the inequality part of the operator makes all the difference.
The following code example from http://msdn.microsoft.com/en-us/library/2cf62fcy.aspx#sectionToggle4 summarizes how C# treats Null:
int? num1 = 10;
int? num2 = null;
if (num1 >= num2)
{
Console.WriteLine("num1 is greater than or equal to num2");
}
else
{
// This clause is selected, but num1 is not less than num2.
Console.WriteLine("num1 >= num2 returned false (but num1 < num2 also is false)");
}
if (num1 < num2)
{
Console.WriteLine("num1 is less than num2");
}
else
{
// The else clause is selected again, but num1 is not greater than
// or equal to num2.
Console.WriteLine("num1 < num2 returned false (but num1 >= num2 also is false)");
}
if (num1 != num2)
{
// This comparison is true, num1 and num2 are not equal.
Console.WriteLine("Finally, num1 != num2 returns true!");
}
// Change the value of num1, so that both num1 and num2 are null.
num1 = null;
if (num1 == num2)
{
// The equality comparison returns true when both operands are null.
Console.WriteLine("num1 == num2 returns true when the value of each is null");
}
/* Output:
* num1 >= num2 returned false (but num1 < num2 also is false)
* num1 < num2 returned false (but num1 >= num2 also is false)
* Finally, num1 != num2 returns true!
* num1 == num2 returns true when the value of each is null
*/
Null == x which is an explicit test for unknown resulting in either true or false. –
Antipathy >= operates on a numeric value; which null is not.
You could overload the >= operator to provide what you desire on a specific type.
Nullable<T>'s code. –
Opportunist What values would you expect?
null == null true
null >= null false
null > null false
null <= null false
null < null false
null != null false
1 == null false
1 >= null false
1 > null false
1 <= null false
1 < null false
1 != null true aka !(1 == null)
>= only means "greater than or equal" when used in that specific well defined way. When used on a class with overloaded operators it means anything the class developer wants it to mean. When applied to a string-like class, it might mean "sorts the same or higher" or it might mean "the same length or longer".
Since by default an int cannot be null and its value will be set to 0, the operator of > and < which is built for int type, expects to work with values and not with nulls.
see my answer to a similar question where I wrote some ways to handle nullable int with the less < and greater > operators https://mcmap.net/q/266175/-c-do-you-need-to-check-if-something-has-a-value-and-if-something-is-greater-than-0
NULL is not zero (numeric or binary value), a zero-length string, or blank (character value). So any comparison operator will always return false on it. Read more about it here
null. Furthermore, comparison operators on C# nullable types are a strange beast that do not necessarily follow the usual rules for null comparisons. –
Bollinger © 2022 - 2024 — McMap. All rights reserved.
int?), then their value is known.null. – WellmanneredNull) but the real problem domain entity/value that the variable is there to represent is Not known.. – Quodlibetval == null. If C# had added a separate keyword for null-checking the way SQL does it, then that would not be the case. – Tackettnullin C#. It's use for nullable types is identical to the use and meaning ofnullin SQL, and should have been treated that way. It's other use, (equivilent to a null pointer in C/C++) means that a reference variable is unassigned. Pity these two very different situations are not represented with a different keyword. The use of same keyword for both does engender some confusion. – Quodlibet