Why can '=' not be overloaded in C#?

Question

I was wondering, why can't I overload '=' in C#? Can I get a better explanation?

Answer 1

Type of Overriding Assignment

There are two type to Override Assignment:

1. When you feel that user may miss something, and you want force user to use 'casting' like float to integer, when you loss the floating value

int a = (int)5.4f;

2. When you want user to do that without even notice that s/he changing the object type

float f = 5;

How to Override Assignment

For 1, use of explicit keyword:

public static explicit override ToType(FromType from){
    ToType to = new ToType();
    to.FillFrom(from);
    return to;
}

For 2, use of implicit keyword:

public static implicit override ToType(FromType from){
    ToType to = new ToType();
    to.FillFrom(from);
    return to;
}

Update:

Note: that this implementation can take place in either the FromType or ToType class, depending on your need, there's no restriction, one of your class can hold all the conversions, and the other implements no code for this.

Answer 2

This code is working for me:

public class Class1
{

    ...

    public static implicit operator Class1(Class2 value)
    {
        Class1 result = new Class1();

        result.property = value.prop;

        return result;

    }

}

Answer 3

Actually, overloading operator = would make sense if you could define classes with value semantics and allocate objects of these classes in the stack. But, in C#, you can't.

Answer 4

Memory managed languages usually work with references rather than objects. When you define a class and its members you are defining the object behavior, but when you create a variable you are working with references to those objects.

Now, the operator = is applied to references, not objects. When you assign a reference to another you are actually making the receiving reference point to the same object that the other reference is.

Type var1 = new Type();
Type var2 = new Type();

var2 = var1;

In the code above, two objects are created on the heap, one referred by var1 and the other by var2. Now the last statement makes the var2 reference point to the same object that var1 is referring. After that line, the garbage collector can free the second object and there is only one object in memory. In the whole process, no operation is applied to the objects themselves.

Going back to why = cannot be overloaded, the system implementation is the only sensible thing you can do with references. You can overload operations that are applied to the objects, but not to references.

Answer 5

Being able to define special semantics for assignment operations would be useful, but only if such semantics could be applied to all situations where one storage location of a given type was copied to another. Although standard C++ implements such assignment rules, it has the luxury of requiring that all types be defined at compile time. Things get much more complicated when Reflection and and generics are added to the list.

Presently, the rules in .net specify that a storage location may be set to the default value for its type--regardless of what that type is--by zeroing out all the bytes. They further specify that any storage location can be copied to another of the same type by copying all the bytes. These rules apply to all types, including generics. Given two variables of type KeyValuePair<t1,t2>, the system can copy one to another without having to know anything but the size and alignment requirements of that type. If it were possible for t1, t2, or the type of any field within either of those types, to implement a copy constructor, code which copied one struct instance to another would have to be much more complicated.

That's not to say that such an ability offer some significant benefits--it's possible that, were a new framework being designed, the benefits of custom value assignment operators and default constructors would exceed the costs. The costs of implementation, however, would be substantial in a new framework, and likely insurmountable for an existing one.

Answer 6

Because it doesn't really make sense to do so.

In C# = assigns an object reference to a variable. So it operates on variables and object references, not objects themselves. There is no point in overloading it depending on object type.

In C++ defining operator= makes sense for classes whose instances can be created e.g. on stack because the objects themselves are stored in variables, not references to them. So it makes sense to define how to perform such assignment. But even in C++, if you have set of polymorphic classes which are typically used via pointers or references, you usually explicitly forbid copying them like this by declaring operator= and copy constructor as private (or inheriting from boost::noncopyable), because of exactly the same reasons as why you don't redefine = in C#. Simply, if you have reference or pointer of class A, you don't really know whether it points to an instance of class A or class B which is a subclass of A. So do you really know how to perform = in this situation?

Answer 7

Because shooting oneself in the foot is frowned upon.

On a more serious note one can only hope you meant comparison rather than assignment. The framework makes elaborate provision for interfering with equality/equivalence evaluation, look for "compar" in help or online with msdn.

Answer 8

You can overload assignment in C#. Just not on an entire object, only on members of it. You declare a property with a setter:

class Complex
{
    public double Real
    {
        get { ... }
        set { /* do something with value */ }
    }

    // more members
}

Now when you assign to Real, your own code runs.

The reason assignment to an object is not replaceable is because it is already defined by the language to mean something vitally important.

Answer 9

It's allowed in C++ and if not careful , it can result in a lot of confusion and bug hunting.

This article explains this in great detail.

http://www.relisoft.com/book/lang/project/14value.html

Answer 10

One possible explanation is that you can't do proper reference updates if you overload assignment operator. It would literally screw up semantics because when people would be expecting references to update, your = operator may as well be doing something else entirely. Not very programmer friendly.

You can use implicit and explicit to/from conversion operators to mitigate some of the seeming shortcomings of not able to overload assignment.

Answer 11

If you overloaded '=' you would never be able to change an object reference after it's been created. ... think about it - any call to theObjectWithOverloadedOperator=something inside the overloaded operator would result in another call to the overloaded operator... so what would the overloaded operator really be doing ? Maybe setting some other properties - or setting the value to a new object (immutability) ? Generally not what '=' implies..

You can, however, override the implicit & explicit cast operators: http://www.blackwasp.co.uk/CSharpConversionOverload.aspx

Answer 12

I don't think there's any really particular single reason to point to. Generally, I think the idea goes like this:

• If your object is a big, complicated object, doing something that isn't assignment with the = operator is probably misleading.

• If your object is a small object, you may as well make it immutable and return new copies when performing operations on it, so that the assignment operator works the way you expect out of the box (as System.String does.)