为什么我们不能在没有装箱的情况下在值类型中重写Equals（）？

Question

I know I can avoid boxing by adding my own Equals implementation.

public struct TwoDoubles
{
    public double m_Re;
    public double m_Im;

    public TwoDoubles(double one, double two)
    {
        m_Re = one;
        m_Im = two;
    }

    public override bool Equals(object ob)
    {
           return Equals((TwoDoubles)ob);
    }
    public bool Equals(TwoDoubles ob)
    {
        TwoDoubles c = ob;
        return m_Re == c.m_Re && m_Im == c.m_Im;
    }
}

I can't call this an override as much as an overload. By the magic of the runtime it does correctly call the correct Equals() implementation based on the type of the caller.

Why can't I override and change the parameter type to TwoDoubles and let boxing occur by the power of the runtime on an as needed basis? Is it because C# doesn't support parameter contravariance (if that's the reason then why is it not supported...seems a small step from object o = new TwoDoubles() )?

UPDATE
Clarification: object is a part of the inheritance hierarchy of a struct. Why can we not specify a more derived type as a parameter to override an implementation from a less derived type? This would allow us to write:

 public override bool Equals(TwoDoubles ob)
 {
        TwoDoubles c = ob;
        return m_Re == c.m_Re && m_Im == c.m_Im;    
 }

Which should be called when the variable is a TwoDouble even if said variable has been boxed into an object type.

Answer 1

Why can't I override and change the parameter type to TwoDoubles?

Because that would not be typesafe!

class B
{
  public virtual void M(Animal animal) { ... }
}
class D : B
{
  public override void M(Giraffe animal) { ... }
}

B b = new D();
b.M(new Tiger());

And now you just passed a tiger to a method that actually only takes a giraffe!

Same thing in your case. You're overriding a method that takes any object with a method that can only take a struct; that's not typesafe.

Is it because C# doesn't support parameter type contravariance ?

No, it is because you are asking for parameter type covariance , which is not typesafe.

C# does not support parameter type contravariance either, but that's not what you're asking for.

Answer 2

You can change the parameter (overload) for Equals , just as you've done, and boxing will occur as needed (ie whenever Equals(object) is called)

Because everything inherits (or implicitly via boxing) from object, you cannot stop people from being able to use Equals(object) on your type. However, by doing so, you get a boxed call.

If you are in control of the calling code, then always use your new overloaded option, ie Equals(TwoDouble)

Note, as one commentor already said, your code is slightly incorrect, do this instead:

public override bool Equals(object ob)
{
  if (ob is TwoDoubles)
    return Equals((TwoDoubles)ob);
  else
    return false;
}
public bool Equals(TwoDoubles c)
{
  return m_Re == c.m_Re && m_Im == c.m_Im;
}

EDIT as has been wisely suggested, you should accomplish this same task but by using the IEquatable interface, in this case IEquatable<TwoDouble> (note, no code change necessary from what we've done as it matches the signature)

Answer 3

If it worked as you suggested, where public override bool Equals(TwoDoubles c) { return m_Re == c.m_Re && m_Im == c.m_Im; } public override bool Equals(TwoDoubles c) { return m_Re == c.m_Re && m_Im == c.m_Im; } was all that was necessary to override the Equals(object) method, what would this code do?

TwoDoubles td = new TwoDoubles();
object o = td;
bool b = o.Equals(new object()); // Equals(object) overridden with Equals(TwoDouble)

What should happen on line 3?

• Should it call Equals(TwoDouble) ? If so, with what parameter? A default TwoDouble with all zeros? That'd violate the rules surrounding equality.
• Should it throw a cast exception? We followed the method signature properly, so that shouldn't happen.
• Should it always return false? Now the compiler has to be aware of what the Equals method means , and will have to treat it differently than other methods.

There's no good way to implement this, and it quickly causes more problems than it solves.