32 bit implicit conversions fail generic overload resolution

Question

I'm experimenting with custom integer types and came across an interesting issue involving generics, implicit conversions, and 32 bit integers.

Below is a stripped down example of how to reproduce the problem. If I have two implicit methods that convert int to MyInt and vice versa, I get a compilation error which looks like C# can't resolve which generic type to use. And it only happens with int or uint. All other integer types work fine: sbyte,byte,short,ushort,long,ulong.

If I remove one of the implicit conversion methods, it also works fine. Something to do with circular implicit conversions?

using Xunit;

public class MyInt
{
    public int Value;

    //If I remove either one of the implicit methods below, it all works fine.
    public static implicit operator int(MyInt myInt)
    {
        return myInt.Value;
    }
    public static implicit operator MyInt(int i)
    {
        return new MyInt() { Value = i };
    }

    public override bool Equals(object obj)
    {
        if (obj is MyInt myInt)
        {
            return this.Value == myInt.Value;
        }
        else
        {
            int other_int = (int)obj;
            return Value == other_int;
        }
    }
}

Below is the test code showing the compilation errors I get when both implicit methods are defined.

public class Test
{
    [Fact]
    public void EqualityTest()
    {
        MyInt myInt = new MyInt();
        myInt.Value = 4 ;

        Assert.Equal(4, myInt.Value);   //Always OK which makes sense

        //Compile errors when both implicit methods defined:
        //  Error CS1503  Argument 1: cannot convert from 'int' to 'string', 
        //  Error CS1503  Argument 2: cannot convert from 'ImplicitConversion.MyInt' to 'string'
        Assert.Equal(4, myInt);
    }
}

I believe C# is complaining about not being able to convert both types to string as that is the type of the last Xunit.Assert.Equal() overload and all the others failed to match:

    //Xunit.Assert.Equal methods:
    public static void Equal<T>(T expected, T actual);
    public static void Equal(double expected, double actual, int precision);
    public static void Equal<T>(T expected, T actual, IEqualityComparer<T> comparer);
    public static void Equal(decimal expected, decimal actual, int precision);
    public static void Equal(DateTime expected, DateTime actual, TimeSpan precision);
    public static void Equal<T>(IEnumerable<T> expected, IEnumerable<T> actual, IEqualityComparer<T> comparer);
    public static void Equal<T>(IEnumerable<T> expected, IEnumerable<T> actual);
    public static void Equal(string expected, string actual, bool ignoreCase = false, bool ignoreLineEndingDifferences = false, bool ignoreWhiteSpaceDifferences = false);
    public static void Equal(string expected, string actual);

I don't think I've made a mistake with the implicit conversions as I can make other similar examples create the same problem when used with 32 bit ints.

I'm testing in a .NET Core 3.0 project.

Any help would be appreciated. Thanks!

Clarification: What I would like to know is why this only fails with 32 bit integers. Implicit conversions are working (confirmed with debugging) when the types are anything else like the example below using a long.

using Xunit;

public class MyLong
{
    public long Value;

    public static implicit operator long(MyLong myInt)
    {
        return myInt.Value;
    }
    public static implicit operator MyLong(long i)
    {
        return new MyLong() { Value = i };
    }

    public override bool Equals(object obj)
    {
        if (obj is MyLong myInt)
        {
            return this.Value == myInt.Value;
        }
        else
        {
            long other_int = (long)obj;
            return Value == other_int;
        }
    }
}

public class Test2
{
    [Fact]
    public void EqualityTest()
    {
        MyLong myLong = new MyLong();
        myLong.Value = 4 ;
        Assert.Equal(4, myLong); //NOTE! `4` is implicitly converted to a MyLong 
                                 //object for comparison. Confirmed with debugging.
    }
}

Answer 1

Something to do with circular implicit conversions?

Yes (though, you've already demonstrated that much by showing that it works fine when one of the conversions is eliminated).

The reason this is happening with int, and not with other types, is that the type of your literal is int. This means that during overload resolution, the compiler can go either way: convert int to MyInt, or convert MyInt to int. Neither option is clearly "better" than the other, so neither of those conversions survive consideration.

Then, having ruled out the closest possible generic version of the method, of the remaining overloads available the only one left is the Equal(string, string) overload (the only other one left with just two parameters is the Equal<T>(IEnumerable<T>, IEnumerable<T>), which is "worse" than the Equal(string, string) overload according to the overload resolution rules). Having found exactly one method that is clearly "better" than any others, the compiler then tries to use that method with your parameters, which of course don't fit, causing the errors to be emitted.

On the other hand…

When you try to call Equal(4, myLong), you've got two incompatible types. A literal having type int, and the MyLong value. In this case, the compiler tries each parameter one by one and finds that when it uses the MyLong type as the type parameter, it is possible to promote the int literal to a long and then implicitly convert that to MyLong. But it can't go the other way. It's not possible to select int as the generic type parameter, because MyLong can't be implicitly converted to int. So in that case, there is a "better" overload to choose, and so it's chosen.

By explicitly specifying the literal's type, you can try different combinations and see this pattern at work. First, I prefer a simpler wrapper class to test with:

public class Wrapper<T>
{
    public T Value;

    public static implicit operator T(Wrapper<T> wrapper) => wrapper.Value;
    public static implicit operator Wrapper<T>(T value) => new Wrapper<T> { Value = value };
}

Then try these:

Wrapper<int> w1 = new Wrapper<int> { Value = 4 };
Wrapper<long> w2 = new Wrapper<long> { Value = 4 };

Assert.Equal(4, w1);        // error
Assert.Equal((short)4, w1); // no error
Assert.Equal(4, w2);        // no error
Assert.Equal(4L, w2);       // error

The only thing that makes int special is that that's the default type for the numeric literal. Otherwise, a type that wraps int works exactly the same as a type that wraps anything else. As long as a conversion is available only in one direction between the two parameters, everything's fine. But when the conversion is available in both directions, the compiler has no choice but to throw up its hands and give up.