Develop Reference

Nullable types and assignment operator

I always thought that the nullable types of the .NET framework where nothing but a nice construct that the framework gave us, but wasn't anything new added to the language itself.
That is, until today, for purposes of a demonstration, I tried to create my own Nullable struct.
I get everything I need, except the capability of doing this:
var myInt = new Nullable<int>(1);
myInt = 1;
The problem is the second statement, as I cannot, by any means, overload the assignment operator.
My question is: Is this a special case in the language where the assignment operator has an overload? If not, how would you approach making that previous example work?
Thanks!

The assignment is question is handled using an implicit operator declared as:
public static implicit operator Nullable<T> (T value)
This is handled without any language-specific features.
The main change to the langauge for nullable support is the ability to write this as:
int? myInt = 1;
You could implement this in your type via:
public static implicit operator Nullable<T> (T value)
{
return new Nullable<T>(value);
}
That being sad, there is a lot of features related to Nullable<T> the C# language and CLR does that can't be duplicated in your code.

Ditto on the other answers, but note that Nullable<T> does do some magic as well.
Quoting from that answer by Lippert
C# automatically lifts operators to nullable. There's no way to say
"automatically lift operators to MyNullable". You can get pretty close
by writing your own user-defined operators though.
C# has special rules for null literals -- you can assign them to
nullable variables, and compare them to nullable values, and the
compiler generates special code for them.
The boxing semantics of nullables are deeply weird and baked into the
runtime. There is no way to emulate them.
Nullable semantics for the is, as and coalescing operators are baked
in to the language.
Nullables do not satisfy the struct constraint. There is no way to
emulate that.
And so on.

Not the assignment operator is overloaded, but the class Nullable<T> specifies an implicit conversion operator which is able to convert T into Nullable<T>.
You can easily add this functionality to your class:
class MyInteger {
private int value;
public MyInteger(int value) { this.value = value; }
public static implicit operator MyInteger(int value) {
return new MyInteger(value);
}
}
And then use the operator in the same way:
MyInteger obj = 123;

According to this page Operator overloading
Note that the assignment operator itself (=) cannot be overloaded.
You can define an implicit operator

Implicit method group conversion gotcha (Part 2)

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.

Operator '==' can't be applied to type T?

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

The conditional operator gets confused, but why? [duplicate]

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.

Why two generic types cannot be compared with '=='?

Here is my simple code:
T a;
T b;
if (a == b)
// sth.
else
// sth. else
When I try to compile, I get an error saying the == operator is invalid for generic types. So I have to use the object.Equals() method.
Doesn't the == operator actually call the Equals method of object? Why can I use the Equals method of two generic types but not the == operator?

operator == must be overloaded in structs in order to be used, hence a completely unconstrained type parameters cannot use it. You can constrain the function to class to allow default reference comparison:
public void Foo<T>() where T : class {
T a = default(T);
T b = a;
if(a == b)
System.Diagnostics.Debug.WriteLine("");
else
System.Diagnostics.Debug.WriteLine("");
}
The above code works because by default, reference types can be used with operator ==:
For reference types other than string,
== returns true if its two operands refer to the same object.
This is why if (new object() == new object()) {} compiles, even though System.Object doesn't overload operator ==.

The == operator is not defined all possible values of T [thanks Daniel] (or on any constraints you may have placed on T, I assume), so you can't use it. You can only call operators, methods, properties on T that can be called on ALL possible types represented by T.
operator == calls 'Equals' in many cases, but that doesn't mean they are the same thing.

The == token is used to represent two different operators in C#. The first of them is applicable only if the types of the operands fit a particular defined overload of the "equality-check" operator. The second test reference equality and is applicable only if one operand is null, one operand is a class type and the other an interface that instances of that type could implement, both are interfaces, both are the same class types, or both are class types and one is a supertype of the other. The first form will not be usable on a generic unless the generic is constrained to a type for which an equality-check overload is defined; the second form is limited to reference types which are known to satisfy a particular one of the indicated conditions. Note that in some cases, the second operator may be used where the first would be intended, e.g. bool IsSame<T>(T p1, T p2) where T:class { return p1==p2; } will compare two variables of type String by using a reference comparison, even though an overload of == is defined for String. This occurs because T isn't well-enough known to apply a String overload of ==, but both operands of == are known to be the same reference type.
It may be worth noting that some other languages use different tokens for the two operations C# performs using ==. VB.NET, for example, uses = for equality comparison and Is for reference equality.