It's pointless in the example given.
While not applicable in this case, there is sometimes a need to cast null (or at least there was before default(T) was added. Consider the following:
void DoSomething(string x) {
...
}
void DoSomething(object x) {
...
}
DoSomething(null); // compiler can't infer the type
DoSomething((string)null); // string type is now explicit
DoSomething(default(string)); // same as previous
EDIT
Just thought of another case where you would have to do the cast when testing equality. If you had an object that had an overloaded == operator that allowed comparison with two reference types, comparing against null would be ambiguous. However because IQueryableContext is most likely an interface and interfaces cannot overload the == operator, I still don't see any valid reason to do it in the example you gave.
class CustomObject {
private string _id;
public CustomObject(string id) {
_id=id;
}
public static bool operator ==(CustomObject lhs, CustomObject rhs) {
if (ReferenceEquals(lhs, rhs)) { return true; }
if (ReferenceEquals(lhs, null)) { return false; }
if (ReferenceEquals(rhs, null)) { return false; }
return lhs._id == rhs._id;
}
public static bool operator !=(CustomObject lhs, CustomObject rhs) {
return !(lhs == rhs);
}
public static bool operator ==(CustomObject lhs, string rhs) {
if (ReferenceEquals(lhs, rhs)) { return true; }
if (ReferenceEquals(lhs, null)) { return false; }
if (ReferenceEquals(rhs, null)) { return false; }
return lhs._id == rhs;
}
public static bool operator !=(CustomObject lhs, string rhs) {
return !(lhs==rhs);
}
}
CustomObject o = null;
if (o == null) {
Console.WriteLine("I don't compile.");
}