Implicit cast operator and the equality operator

Question

Say I have a simple object which supports implicit casting to System.String

public sealed class CompanyCode
{
    public CompanyCode(String value)
    {
        // Regex validation on value format
        _value = value;
    }

    private readonly String _value;

    public override String ToString()
    {
        return _value;
    }

    static public implicit operator String(CompanyCode code)
    {
        if(code == null)
            return null;

        return code.ToString();
    }
}

Now lets say in another part of my program I perform a comparison with a string:

var companyCode = { some company code object }

if (companyCode == "MSFTUKCAMBS")
    // do something...

What is the compiler doing with the == operator? Is it implicitly casting companyCode to a string and running the System.String == implementation? Is it using the System.Object == implementation? Or will the compiler just complain at me? (I don't have a compiler to check this right now).

As far as I can see I have a couple of other options.

• Implement an ==(String x) operator on CompanyCode.
• Implement the IEquatable<String> interface on CompanyCode.

Would any (or both) of these options be preferable?

Answer 1

I personally would suggest do not use operator overloading, in these cases. It's kind of confusing looking on the code, to understand what is going on.

It's a much better, imo, having some function that esplicitly manifests comparison operation, or, like Jon suggests, use a property.

In short make it clear for the reader of your code what you're gonna to compare.

Answer 2

Say I have a simple object which supports implicit casting to System.String

I would question this design decision to start with. The fact that it's brought up this question of operator overloading suggests that your colleagues will be asking the same sort of questions. I don't even know the answer (in terms of what the compiler will do) off the top of my head.

I definitely wouldn't suggest implementing IEquatable<string>, as then x.Equals(y) won't be symmetric with y.Equals(x). You could implement two overloads of == in your class, both ways round... but then it wouldn't be consistent with Equals.

I would suggest just having a property called Value or Code of type string, then you can use:

if (companyCode.Value == "MSFTUKCAMBS")

and it will be immediately clear what that means.

Basically, I think the situations where implicit conversions are appropriate are very few and far between.

From the Design Guidelines for Class Library Developers

Do not provide a conversion operator if such conversion is not clearly expected by the end users.

Is there such a clear expectation here?

Answer 3

It will implicitly cast to a string and check equality using the string's == operator. For the case you show - every way you offered is suitable, but every way has a different purpose and meaning.

Implicitly conversion should usually be avoided. Implementing the == is to allow comparing with a string, and IEquatable is simply to allow using the class as type IEquatable, for outside code references. The IEquatable may very well just return the == result.

For this case, I would choose the == operator overloading, unless you have any other purpose for using implicit conversion.

Also, if you use implicit conversions, it will be a bit uglier code-wise but smarter robust-wise to overload an EXPLICIT conversion, and not an implicit one, so whenever one wants to convert your class to a string, he will have to cast it using (string)obj, which is also a good reminder for whats really happening in the code.