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;
    }

    readonly String _value;

    public override String ToString() => _value;

    static public implicit operator String(CompanyCode code) =>
        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

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.