This question already has answers here:
Nullable types and the ternary operator: why is `? 10 : null` forbidden? [duplicate]
(9 answers)
Conditional operator cannot cast implicitly?
(3 answers)
Closed 9 years ago.
Assume two classes, both descendants of the same superclass, like this:
class MySuperClass{}
class A : MySuperClass{}
class B : MySuperClass{}
Then this assignment won't pass the compiler:
MySuperClass p = myCondition ? new A() : new B();
The compiler complains that A and B are not compatible (Type of conditional expression cannot be determined because there is no implicit conversion between 'A' and 'B' [CS0173] ). But they are both of type MySuperClass, so in my opinion this should work. Not that it's a big deal; a simple cast is all it takes to enlighten the compiler. But surely it's a snag in the C# compiler? Don't you agree?
The results of the conditional should be of the same type. They are not.
From MSDN, (?: Operator):
Either the type of first_expression and second_expression must be the same, or an implicit conversion must exist from one type to the other.
Since A and B are not the same type and you don't seem to have defined an implicit conversion, the compiler complains.
Look to section 7.14 of the language specification
The second and third operands, x and
y, of the ?: operator control the type
of the conditional expression.
· If x has type X and y has
type Y then
o If an implicit conversion (§6.1)
exists from X to Y, but not from Y to
X, then Y is the type of the
conditional expression.
o If an implicit conversion (§6.1)
exists from Y to X, but not from X to
Y, then X is the type of the
conditional expression.
o Otherwise, no expression type can
be determined, and a compile-time
error occurs.
· If only one of x and y has a
type, and both x and y, of
areimplicitly convertible to that
type, then that is the type of the
conditional expression.
· Otherwise, no expression type can be determined, and a compile-time error occurs.
Essentially, the operands must be convertible to one another, not mutually convertible to some other type.
It's why you need to make an explicit cast in your example or in cases such as nullables (int? foo = isBar ? 42 : (int?)null). The declaration type does not impact the evaluation, the compiler must figure it out from the expression itself.
Check out this blog for some interesting articles on why C# compiler does/doesn't do things that are 'obvious' to you. The blog is written by Eric Lippert, one of the C# compiler developers.
The compiler doesn't try to look for a common ancestor, so you need an explicit cast to show which ancestor you wanted to treat it as; In your case:
MySuperClass p = myCondition ? (MySuperClass)(new A()) : (MySuperClass)(new B());
This means that the conditional operator has both sides returnin gthe same type, which satisfies the compiler.
The conditional operator (as with any other operator) has to define the type that its expression represents. In the case of the conditional operator, it has a two-step process:
Are the operands of the same type? If so, that is the type of the expression.
Is there an implicit conversion from one of the operand types to the other (but not in both directions)? If so, then the "other" is the type of the expression.
There's no ancestry search, as implementing that could lead down a slippery slope of ambiguity in what you, as a developer, could specify in that expression. Should everything lead to object? What about value types, which would then be implicitly boxed? What about interfaces? If there's more than one common interface between the two types, which one should be chosen?
In your case, as you've discovered, you need to upcast one of the operands to the parent type. Once you do that, rule 2.) is satisfied (there is always an implicit conversion going from a more specific type to a less specific type).
Note that you only need to apply the cast to one of the operands, not both.
Rowland Shaw summed it up pretty well, but to see why a common ancestor isn't used implicitly, consider what would happen if both classes were also to implement a particular interface. The compiler wouldn't be able to work out which to use for the type of the conditional operator, and so it would be forced to use object instead.
Related
As I was answering this question, I observed a very strange behaviour unique to switch expressions - they seem to be able to infer their types when they have an ambiguous type.
For example, This doesn't compile
double a = new Random().Next(2) == 0 ? (short)1 : (uint)1;
because the compiler "doesn't look" at the double a part when type checking, and sees that the expression is either of type short or uint. An expression can't be of two types, so an error is output. This is fine. It is quite well-known that C# doesn't look at the type of variable that you are assigning to, just like in generics:
static T F<T>() => default(T);
double d = F(); // can't infer that T is double
However, switch expressions break this "rule". If I rewrite the first code snippet with switch expressions:
double a = (new Random().Next(2) == 0) switch {
true => (short)1,
false => (uint)1
};
Then suddenly it compiles! Unlike the first code snippet, the compiler seems to have paid attention to the double a part and figured out that I want a double. I tried looking at the docs for switch expressions, but it doesn't mention that it will perform any automatic conversions to the result type or anything like that.
Why is C# so smart when dealing with switch expressions, but not with other kind of expressions (such as ternary operator)?
From the C# lang proposal for switch expressions;
The type of the switch_expression is the best common type of the expressions appearing to the right of the => tokens of the switch_expression_arms if such a type exists and the expression in every arm of the switch expression can be implicitly converted to that type. In addition, we add a new switch expression conversion, which is a predefined implicit conversion from a switch expression to every type T for which there exists an implicit conversion from each arm's expression to T.
The best common type?
In some cases, a common type needs to be inferred for a set of expressions. In particular, the element types of implicitly typed arrays and the return types of anonymous functions with block bodies are found in this way.
Intuitively, given a set of expressions E1...Em this inference should be equivalent to calling a method
Tr M<X>(X x1 ... X xm)
with the Ei as arguments.
More precisely, the inference starts out with an unfixed type variable X. Output type inferences are then made from each Ei to X. Finally, X is fixed and, if successful, the resulting type S is the resulting best common type for the expressions. If no such S exists, the expressions have no best common type
Since this doesn't compile, with a "no best type.." error;
var x = (id == 0) switch
{
true => (short)1,
false => (uint)1
};
Your example double x ... constrains the output type, changing how the types of the switch expressions are inferred. But that's just me guessing.
Whereas the conditional operator has very strict rules;
The second and third operands, x and y, of the ?: operator control the type of the conditional expression.
If x has type X and y has type Y then
If an implicit conversion
(Implicit conversions) exists from X to Y, but not from Y to X, then Y
is the type of the conditional expression.
If an implicit conversion
(Implicit conversions) exists from Y to X, but not from X to Y, then X
is the type of the conditional expression.
Otherwise, no expression
type can be determined, and a compile-time error occurs.
If only one
of x and y has a type, and both x and y, of are implicitly convertible
to that type, then that is the type of the conditional expression.
Otherwise, no expression type can be determined, and a compile-time
error occurs.
TLDR; the type inference / promotion rules are very different.
This question already has answers here:
Implicit conversion issue in a ternary condition [duplicate]
(4 answers)
Closed 8 years ago.
I am wondering why this line of code doesn't compile:
ILogStuff Logger = (_logMode) ? new LogToDisc() : new LogToConsole();
Note that both classes LogToDiscand LogToConsole implement ILogStuff, and _logMode is a boolean variable. The error message I get is:
Error 3: Type of conditional expression cannot be determined because there is no implicit conversion between 'xxx.LogToDisc' and 'xxx.LogToConsole'
But why should there be one? What am I missing?
There is not implicit conversion available for ternary operator. You need to cast the returned object by ternary operator to ILogStuff, This is very well explain in Eric Lippert's answer for the question Implicit conversion issue in a ternary condition
ILogStuff Logger = (_logMode) ? (ILogStuff) new LogToDisc() : (ILogStuff) new LogToConsole();
From chapter 7.13 of the C# Language Specification:
The second and third operands of the ?: operator control the type of the conditional expression. Let X and Y be the types of the second and third operands. Then,
If X and Y are the same type, then this is the type of the conditional expression.
Otherwise, if an implicit conversion (§6.1) exists from X to Y, but not from Y to X, then Y is the type of the conditional expression.
Otherwise, if an implicit conversion (§6.1) exists from Y to X, but not from X to Y, then X is the type of the conditional expression.
Otherwise, no expression type can be determined, and a compile-time error occurs.
You need to cast to the interface:
ILogStuff Logger = (_logMode) ? (ILogStuff)new LogToDisc() : new LogToConsole();
The specification describes the behaviour of the conditional operator:
7.14 Conditional operator
The second and third operands, x and y, of the ?: operator control the
type of the conditional expression.
If x has type X and y has type
Y then
If an implicit conversion (§6.1) exists from X to Y, but
not from Y to X, then Y is the type of the conditional expression.
If an implicit conversion (§6.1) exists from Y to X, but not from
X to Y, then X is the type of the conditional expression.
Otherwise, no expression type can be determined, and a
compile-time error occurs.
There is no implicit conversion between LogToDisc and LogToConsole in either direction, so the compilation fails. If you fix one of the types to ILogStuff the implicit conversion from the other type will exist.
The message is correct, there is no implicit conversion between those two types, they just share the common interface. But of course shared parent do not imply possiblity of casting, in the same way as int is not implicty covertible into string although both have common parent - Object.
The ternary operator expects that the result type of both possible values will be the same - in terms of possibility to make an implicit cast between them. So you must tell him, that the first return value is of type ILogStuff:
ILogStuff Logger = (_logMode) ? (ILogStuff)new LogToDisc() : new LogToConsole();
Then, the second possible value is proper one - there exists implicit conversion between LogToConsole type and ILogStuff interface.
The expression must return a common type of both implementations. By explicitly casting the instances to the interface, the expression compiles:
ILogStuff Logger = (_logMode) ?
(ILogStuff)new LogToDisc() :
(ILogStuff)new LogToConsole();
Adil has provided the section that determines this behaviour, but I'd like to explain why this behaviour is sensible.
bool ? val1 : val2
This is an expression. Expressions need to have a type that is determinable at compile time. This makes it faster, and catches errors sooner.
Now, if:
val is an instance of MyObject1 which extends SomeParent and implements MyInterface,
and val2 is and instance of MyObject2 which extends SomeParent and implements MyInterface
How do we determine the compile-time type of this expression? We could try to find a common type between MyObject1 and MyObject2. What's the most obvious solution? Do you call it a SomeParent or a MyInterface? and If they had 2 Interfaces, which one would you pick?
The problem is this is a mess, and would require some pretty contrived rules(and in fact there are more examples that would be less clear) that at the end of the day, would be less intuitive than the current definition.
Simplified from this question and got rid of possible affect from LinqPad(no offsensive), a simple console application like this:
public class Program
{
static void M() { }
static void Main(string[] args)
{
Action a = new Action(M);
Delegate b = new Action(M);
Console.WriteLine(a == b); //got False here
Console.Read();
}
}
The "false" results from the operator ceq in CIL of the code above(visit the original question for details). So my questions are:
(1) Why == is translating to ceq instead of call Delegate Equals?
Here I don't care about the (un)wrapping between Delegate and Action. At the very last, when evaluating a == b, a is of type Action while b is a Delegate. From the spec:
7.3.4 Binary operator overload resolution
An operation of the form x op y, where op is an overloadable binary operator, x is an expression
of type X, and y is an expression of type Y, is processed as follows:
• The set of candidate user-defined operators provided by X and Y for
the operation operator op(x, y) is determined. The set consists of the
union of the candidate operators provided by X and the candidate
operators provided by Y, each determined using the rules of §7.3.5. If
X and Y are the same type, or if X and Y are derived from a common
base type, then shared candidate operators only occur in the combined
set once.
• If the set of candidate user-defined operators is not
empty, then this becomes the set of candidate operators for the
operation. Otherwise, the predefined binary operator op
implementations, including their lifted forms, become the set of
candidate operators for the operation. The predefined implementations
of a given operator are specified in the description of the operator
(§7.8 through §7.12).
• The overload resolution rules of §7.5.3 are
applied to the set of candidate operators to select the best operator
with respect to the argument list (x, y), and this operator becomes
the result of the overload resolution process. If overload resolution
fails to select a single best operator, a binding-time error occurs.
7.3.5 Candidate user-defined operators
Given a type T and an operation operator op(A), where op is an overloadable operator and A is an argument list, the set of candidate user-defined operators provided by
T for operator op(A) is determined as follows:
• Determine the type
T0. If T is a nullable type, T0 is its underlying type, otherwise T0
is equal to T.
• For all operator op declarations in T0 and all lifted
forms of such operators, if at least one operator is applicable
(§7.5.3.1) with respect to the argument list A, then the set of
candidate operators consists of all such applicable operators in T0.
• Otherwise, if T0 is object, the set of candidate operators is empty.
• Otherwise, the set of candidate operators provided by T0 is the set
of candidate operators provided by the direct base class of T0, or the
effective base class of T0 if T0 is a type parameter.
From the spec, a and b have a same base class Delegate, obviously the operator rule == defined in Delegate should be applied here(the operator == invokes Delegate.Equals essentially). But now it looks like the candidate list of user-defined operators is empty and at last Object == is applied.
(2) Should(Does) the FCL code obey the C# language spec? If no, my first question is meaningless because something is specially treated. And then we can answer all of these questions using "oh, it's a special treatment in FCL, they can do something we can't. The spec is for outside programmers, don't be silly".
Compiler works very different and unusual with delegates. There are a lot of implicit handling. Notice, that 'common base type' rule in this guide is applied to 'user-defined operators'. Delegates are internal and system. For example, you can write Action a = M; instead of Action a = new Action(M);. And you can add a += M; after that. Check what happens in CIL, it is interesting at a first time.
Further more: it is dangerous and non-trivial to compare delegates. Every delegate is actually multicast delegate. You can add several function pointers to the same delegate. Does delegates [L(); M(); N();] equals to delegate [M();] ? Function pointer contains class instance (for instance method). Does [a.M();] equals to [b.M();]? All that depends on a case, and comparison implementation requires to step through invocation list.
Delegates inheritance from common base type Delegate is implicit and this problem you can face in another scenarios, e.g. generic constraint: you can not specify Delegate as a constraint to generic parameter T. Here compiler explicitly declines this. The same about creating your own classes, inherited from Delegate.
This is answer to both questions - 'Delegate' is not purely FCL, it is tightly coupled with compiler. If you really want Microsoft's delegate comparer behavior - just call explicitly Equals(a, b)
warning CS0253: Possible unintended reference comparison; to get a value comparison, cast the right hand side to type 'System.Action'
That is the warning you get for that C# code. Don't ignore that warning, the C# team was well aware that the code they generated for this comparison was unexpected. They didn't have to generate that code, they could easily have done what you expected. Like this code does:
Module Module1
Sub M()
End Sub
Sub Main()
Dim a = New Action(AddressOf M)
Dim b = DirectCast(New Action(AddressOf M), [Delegate])
Console.WriteLine(a = b) ''got True here
Console.Read()
End Sub
End Module
Which generates almost the same MSIL, except that instead of ceq you get:
IL_001d: call bool [mscorlib]System.Delegate::op_Equality(class [mscorlib]System.Delegate,
class [mscorlib]System.Delegate)
Which what you hoped the C# code would do. That was VB.NET code, in case you didn't recognize it. Otherwise the reason that Microsoft keeps two major managed languages around, even though they have very similar capabilities. But with very different usability choices. Whenever there was more than one way to generate code, the C# team consistently chose for performance, the VB.NET team consistently for convenience.
And performance certainly is the key here, comparing delegate objects is expensive. The rules are spelled out in Ecma-335, section II.14.6.1. But you can reason it out for yourself, there is a lot of checking to do. It needs to check if the delegate target object is compatible. And for each argument it must check if the value is convertible. Expense that the C# team does not want to hide.
And doesn't, you get the warning to remind you that they made the unintuitive choice. .
There are two types of operators: user-defined operators and predefined operators. Section 7.3.5 "Candidate user-defined operators" does not apply to predefined operators.
For example, the operators on decimal look like user-defined operators in a decompiler, but C# treats them as predefined operators and applies numeric promotion to them (numeric promotion is not applied to user-defined operators).
Section 7.10.8 "Delegate equality operators" defines operator ==(Delegate, Delegate) as a predefined operator, so I'd think that all the rules about user-defined operators don't apply to this operator (although this isn't 100% clear in the spec as in this case, the predefined operator doesn't apply whenever the user-defined operator would).
Every delegate type implicitly provides the following predefined comparison operators:
bool operator ==(System.Delegate x, System.Delegate y);
bool operator !=(System.Delegate x, System.Delegate y);
But System.Delegate itself is not considered a delegate type, so the only candidate for overload resolution is operator ==(object, object).
The key here is that the == operator and the Equals method for the Delegate type are two different things. For reference types, the == looks to see if both references point to the same object unless the == operator is overridden (see: == Operator (C#)).
Since you are creating two different Action objects, even though they internally invoke the same method, they are different objects in different locations in memory, and are not of a value or string type, so == is in this case a ReferenceEquals, and does not invoke the Delegate.Equals method, which has been overridden to see if the two objects do the same thing. For reference types other than string, this is the default behavior of == or Equals.
If var keyword is resolved at compile time, how does the following work?
class A {
}
class B : A {
}
int k = 1;
var x = (k < 0) ? new B() : new A();
Edit:
I finally understood that the problem is not about the var itself, but about the behaviour of the ?: operator. For some reason, I thought that the following could be possible:
object x = something ? 1 : ""
and that's not possible at all :)
Related question (about ternary operator):
Why assigning null in ternary operator fails: no implicit conversion between null and int?
The result is of type A, because both of the variables are of type A, and at least one of them is directly of type A (not through some conversion).
The compiler takes a look at both parts of the ternary expression, and if one of them is a subtype of the other, the entire expression becomes the more general supertype.
However, if neither is directly of the common type, then a compiler error occurs, probably because it doesn't know how much to upcast for you (and it doesn't feel like finding out).
See here:
The conditional operator (?:) returns one of two values depending on the value of a Boolean expression. Following is the syntax for the conditional operator.
condition ? first_expression : second_expression;
[...]
Either the type of first_expression and second_expression must be the same, or an implicit conversion must exist from one type to the other.
The result is A. An easy way to confirm it is to place your mouse over the var.
I haven't tested this degenerate case. But I would bet either (1) compiler complains or (2) 'x' is of type 'A'.
I thought this method was valid but I was wrong:
static void Equals<T>(T x, T y)
{
return x == y; //operator == can't be applied to type T
}
After reading the specifiation (§7.2.4 in v3.0 and §7.3.4 in v4.0):
7.2.4 Binary operator overload resolution
An operation of the form x
op y, where op is an overloadable
binary operator, x is an expression of
type X, and y is an expression of type
Y, is processed as follows:
The set of candidate user-defined operators
provided by X and Y for the operation
operator op(x, y) is determined. The
set consists of the union of the
candidate operators provided by X and
the candidate operators provided by Y,
each determined using the rules of
§7.2.5. If X and Y are the same type,
or if X and Y are derived from a
common base type, then shared
candidate operators only occur in the
combined set once.
If the set of
candidate user-defined operators is
not empty, then this becomes the set
of candidate operators for the
operation. Otherwise, the predefined
binary operator op implementations,
including their lifted forms, become
the set of candidate operators for the
operation. The predefined
implementations of a given operator
are specified in the description of
the operator (§7.7 through §7.11).
The overload resolution rules of §7.4.3 are applied to the set of candidate operators to select the best operator with respect to the argument list (x, y), and this operator becomes the result of the overload resolution process. If overload resolution fails to select a single best operator, a compile-time error occurs.
In step 2 I think this predefined implementation should be applied:
bool operator ==(object x, object y);
bool operator !=(object x, object y);
since everything in C# derives from Object. How can a compile-time error occurs in step 3? I don't think it's possible that "overload resolution fails to select" in this case.
EDIT The question came to my mind when I was implementing something like this:
class EnumComparer<TEnum> : IEqualityComparer<TEnum>
{
public bool Equals(TEnum x, TEnum y)
{
return x == y;
}
public int GetHashCode(TEnum obj)
{
return (int)obj;
}
}
I'm afraid I need to build a expression and invoke it dynamicly in Equals method.
Good for you for reading the spec, but you stopped reading too soon. Had you read further you would have gotten to this bit:
The predefined reference type equality operators require one of the following:
Both operands are a value of a type known to be a reference-type or the literal null. Furthermore, an explicit reference conversion exists from the type of either operand to the type of the other operand.
One operand is a value of type T where T is a type-parameter and the other operand is the literal null. Furthermore T does not have the value type constraint.
Unless one of these conditions are true, a binding-time error occurs. (*)
The error isn't from overload resolution; the error is that overload resolution would have chosen the predefined reference type equality operator, and you don't have reference types.
Consider your code. What stops T from being a value type with no equality operator defined on it? Nothing. Suppose we fell back to the object version; both operands would box to different locations and therefore be reference-unequal, even if they had the same content. Since that is slow, confusing and wrong, it is illegal to even try.
Why are you trying to do this thing in the first place? If your method worked, which it doesn't, then your method would be worse than simply using == in the first place. What is the value you intend to add to the world with this method?
(*) I've reported the grammatical error in this sentence to the spec maintainers.
That would possibly work if it knew that where T : class, doing a reference comparison. Operators generally have very little support with generics, but there are workarounds. MiscUtil offers indirect support for operators on generics, otherwise EqualityComparer<T>.Default.Equals(x,y) is a good choice.
I like using EqualityComparer<T>.Default for this.
It is based on the overridden Equals method, but uses IEquatable<T> when available, avoiding boxing on value types implementing it.
EqualityComparer<T>.Default.Equals(x, y)
use .Equals() method and be sure that the T implement IComparable