"is" operator behaving a bit strangely

Question

1) According to my book, is operator can check whether expression E (E is type) can be converted to the target type only if E is either a reference conversion, boxing or unboxing. Since in the following example is doesn’t check for either of the three types of conversion, the code shouldn’t work, but it does:

  long l;     // EDIT - I forgot to add this line of code in my initial post
  int i=100;
  if (i is long) //EDIT - in my initial post I've claimed condition returns true, but it really returns false
           l = i;

2)

a)

    B b;
    A a = new A();
    if (a is B)
        b = (B)a;
    int i = b.l;


    class A { public int l = 100; }
    class B:A { }

The above code always causes compile time error “Use of unassigned variable”. If condition a is B evaluates to false, then b won’t be assigned a value, but if condition is true, then it will. And thus by allowing such a code compiler would have no way of knowing whether the usage of b in code following the if statement is valid or not ( due to not knowing whether a is b evaluates to true or false) , but why should it know that? Intsead why couldn’t runtime handle this?

b) But if instead we’re dealing with non reference types, then compiler doesn’t complain, even though the code is identical.Why?

        int i = 100;
        long l;
        if (i is long)
            l = i;

thank you

Answer 1

The real difference is that in the int case, you are talking about the definite assignment of a field (l). Fields are always definitely assigned (even without the =100). In the B case, you are talking about the definite assignment of the local variable (b); local variables do not start as definitely assigned.

That's all it is.

---

int i=100; if (i is long) //returns true, indicating that conversion is possible

1: I don't think this returns true at all; for me it shows an IDE warning about never being true. Looking in reflector, the compiler completely removes this branch. I guess the compiler is obliged to at least compile on the grounds that it could (in theory) box and test. But it already knows the answer, so it snips it.

2: I still get the "unassigned variable" compiler error; due to "definite assignment"

Answer 2

This has nothing to do with the is operator. The compiler sees that there are two possible paths, only one of which will assign a value to b.

When dealing with value types, the compiler knows that l gets implicitly initialized to the value 0.

Answer 3

The compiler behaves correctly - why should it compile without errors if there is a use of an unassigned variable? You cannot work with b.l if b is unassigned as the compiler checks that there is a code path that does not instantiate b which is why it throws an error ...

Answer 4

In your code, class B derives from A. This means:

a is B // evaluates to false
b is A // evaluates to true

This means that the body of the if block won't be entered, and b will not be assigned.

Stephen Cleary also has a point. I don't know how sophisticated the compiler is when evaluating if values are assigned.

Answer 5

Okay, the MSDN says on is:

The is operator is used to check whether the run-time type of an object is compatible with a given type.

An is expression evaluates to true if both of the following conditions are met:

• expression is not null.
• expression can be cast to type. That is, a cast expression of the form (type)(expression) will complete without throwing an exception.

That would fit pretty well with 1, but 2 is another topic and correct (think about it).

However, the following code writes 0 to the output:

    int i = 1;
    long l = 0;
    if (i is long)  {
        l = i;
    }
    Console.WriteLine(l);

Therefore it seems that the note in the is MSDN documentation is correct as well:

Note that the is operator only considers reference conversions, boxing conversions, and unboxing conversions. Other conversions, such as user-defined conversions, are not considered by the is operator.