Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>This behaviour is defined in the C# specification (<a href="http://www.ecma-international.org/publications/standards/Ecma-334.htm" rel="noreferrer">ECMA-334</a>) in section 14.2.7 (I have highlighted the relevant part):</p> <blockquote> <p>For the relational operators</p> <pre><code>&lt; &gt; &lt;= &gt;= </code></pre> <p>a lifted form of an operator exists if the operand types are both non-nullable value types and if the result type is <code>bool</code>. The lifted form is constructed by adding a single <code>?</code> modifier to each operand type. <strong>The lifted operator produces the value <code>false</code> if one or both operands are <code>null</code></strong>. Otherwise, the lifted operator unwraps the operands and applies the underlying operator to produce the <code>bool</code> result.</p> </blockquote> <p>In particular, this means that the usual laws of relations don't hold; <code>x &gt;= y</code> does not imply <code>!(x &lt; y)</code>.</p> <h2>Gory details</h2> <p>Some people have asked why the compiler decides that this is a lifted operator for <code>int?</code> in the first place. Let's have a look. :)</p> <p>We start with 14.2.4, 'Binary operator overload resolution'. This details the steps to follow.</p> <ol> <li><p>First, the user-defined operators are examined for suitability. This is done by examining the operators defined by the types on each side of <code>&gt;=</code>... which raises the question of what the type of <code>null</code> is! The <code>null</code> literal actually doesn't have any type until given one, it's simply the "null literal". By following the directions under 14.2.5 we discover there are no operators suitable here, since the null literal doesn't define any operators.</p></li> <li><p>This step instructs us to examine the set of predefined operators for suitability. (Enums are also excluded by this section, since neither side is an enum type.) The relevant predefined operators are listed in sections 14.9.1 to 14.9.3, and they are all operators upon primitive numeric types, along with the lifted versions of these operators (note that <code>string</code>s operators are not included here). </p></li> <li><p>Finally, we must perform overload resolution using these operators and the rules in 14.4.2.</p></li> </ol> <p>Actually performing this resolution would be extremely tedious, but luckily there is a shortcut. Under 14.2.6 there is an informative example given of the results of overload resolution, which states:</p> <blockquote> <p>...consider the predefined implementations of the binary * operator:</p> <pre><code>int operator *(int x, int y); uint operator *(uint x, uint y); long operator *(long x, long y); ulong operator *(ulong x, ulong y); void operator *(long x, ulong y); void operator *(ulong x, long y); float operator *(float x, float y); double operator *(double x, double y); decimal operator *(decimal x, decimal y); </code></pre> <p>When overload resolution rules (§14.4.2) are applied to this set of operators, the effect is to select the first of the operators for which implicit conversions exist from the operand types.</p> </blockquote> <p>Since both sides are <code>null</code> we can immediately throw out all unlifted operators. This leaves us with the lifted numeric operators on all primitive numeric types. </p> <p>Then, using the previous information, we select the first of the operators for which an implicit conversion exists. Since the null literal is implicitly convertible to a nullable type, and a nullable type exists for <code>int</code>, we select the first operator from the list, which is <code>int? &gt;= int?</code>.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload