Is there a difference between "!=" and "is not" in C#?

Solution 1:

Comparison table:

Common examples:

To answer the OP's question directly and specifically:

if( x != y ) { }
// vs:
if( x is not y ) { }

• If x is an integral value-type (e.g. int/ Int32) and y is a const-expression (e.g. const int y = 123;) then no, there is no difference, and both statements result in the same .NET MSIL bytecode being generated (both with and without compiler optimizations enabled):

  

• If y is a type-name (instead of a value name) then there is a difference: the first if statement is invalid and won't compile, and the if( x is not y ) statement is a type pattern match instead of a constant pattern match.

Footnotes:

1. "Constant Pattern": "When the input value is not an open type, the constant expression is implicitly converted to the type of the matched expression".

2. x is not null is more analogous to !(x == null) than x != null.

3. C# 7.0 introduced some limited forms of constant-pattern matching, which was further expanded by C# 8.0, but it wasn't until C# 9.0 that the not negation operator (or is it a modifier?) was added.

4. Given a non-constrained generic method, like so:

   void Foo<T>( T x )
   {
       if( x == null ) { DoSomething(); }
   
       DoSomethingElse();
   }
   

   ...when the JIT instantiates the above generic method (i.e.: monomorphization) when T is a value-type (struct) then the entire if( x == null ) { DoSomething(); } statement (and its block contents) will be removed by the JIT compiler ("elision"), this is because a value-tupe can never be equal to null. While you'd expect that to be handled by any optimizing compiler, I understand that the .NET JIT has specially hardcoded rules for that particular scenario.

   • Curiously in earlier versions of C# (e.g. 7.0) the elision rule only applied to the == and != operators, but not the is operator, so while if( x == null ) { DoSomething(); } would be elided, the statement if( x is null ) { DoSometing(); } would not, and in fact you would get a compiler error unless T was constrained to where T : class. Since C# 8.0 this seems to now be allowed for unconstrained generic types.

5. Surprisingly I couldn't find an authoritative source on this (as the published C# specs are now significantly outdated; and I don't want to go through the csc source-code to find out either).

   • If neither the C# compiler or JIT do apply impossible-branch-elision in generic code with Constant-pattern expressions then I think it might simply because it's too hard to do at-present.

6. Note that a constant-expression does not mean a literal-expression: you can use named const values, enum members, and so on, even non-trivial raw expressions provided all sub-expressions are also constant-expressions.

   • I'm curious if there's any cases where static readonly fields could be used though.

7. Note that in the case of typeof(X) != y.GetType(), this expression will return true when X is derived from y's type (as they are different types), but x is not Y is actually false because x is Y (because x is an instance of a subclass of Y). When using Type it's better to do something like typeof(X).IsSubclassOf(y.GetType()), or the even looser y.GetType().IsAssignableFrom(typeof(X)).

   • Though in this case, as Char is a struct and so cannot participate in a type-hierarchy, so doing !x.IsSubclassOf(typeof(Char)) would just be silly.

Solution 2:

An additional difference to the ones listed in the excellent accepted answer is that (since C# 7.0), is between two NaN values is a pattern that matches, because x.Equals(y) is true when both x and y are NaN, and a NaN value does not have an integral type. Therefore, is not between two NaN values returns that the pattern is not a match.

However, C# follows IEEE floating-point and C by specifying that a != comparison between two NaN values is true and an == comparison between them is false. This was mainly because the Intel 8087 floating-point co-processor back in 1980 had no other way to test for NaN.