Invalid implicit conversion from long to int

[myblindy]

Version Used: C# 12, though it's present in all of them

Steps to Reproduce:

public struct UnixTime
{
    public static explicit operator UnixTime(int i) => default;
}

public class C {
    public UnixTime M(long i) =>
        (UnixTime)i;
}

Demo here

Diagnostic Id:

None

Expected Behavior:

As per the built-in numeric conversion rules, the code above should fail.

Actual Behavior:

Instead it inserts an implicit conversion from long to int, then matches the explicit operator's signature:

        IL_0000: ldarg.1
        IL_0001: conv.i4
        IL_0002: call valuetype UnixTime UnixTime::op_Explicit(int32)
        IL_0007: ret

[RioMcBoo]

it bugs with other types also (unsigned/unsigned and signed/signed)
[short to int]
[ushort to uint]

just look for that case (all of them):
[ushort to long]
[ushort to ulong]
[short to long]
[short to ulong]

and etc

It looks like all of these types share an implicit float conversion operator.

[gurustron]

As far as I understand this is not a bug but behavior defined in the spec (10.5.5 User-defined explicit conversions) which allows using intermediate standard explicit conversions in this case.

[RioMcBoo]

I thought about this too. But the point is that the compiler never makes 2 implicit conversions for the same type at once. But it can convert both operands once each to a common type.

And as it turns out, all these types have a common type - float. Look, at least - why long can be converted to float?

Anyway, if it is possible (i am not sure) - it is a mistake, because you need to further convert the result of the operation to a narrower type. And here an explicit conversion is called, which means that the programmer agrees to data loss

[RioMcBoo]

For example:

Pls make difference: with this case

I think not a single person would ever guess in his life that he could lose data here. This is not obvious at all. Moreover, this makes it difficult to create a standard wrapper type for more strictly code typing.

For example, I encountered this problem when I opened a project where all the variables were of type uint/int, and at the same time they stored seconds, milliseconds, with and without negative values, as well as Unix time. I've been back for 2 weeks now just to get everything in order, and now I got this surprise ((

[RioMcBoo]

As far as I understand this is not a bug but behavior defined in the spec (10.5.5 User-defined explicit conversions) which allows using intermediate standard explicit conversions in this case.

Now I see your point, this is not a bug. A BUG is in opposite hand - finally it still looks weird because I cannot make an analogue of basic types in total equalence:

look at two versions of S and MS methods:

• one of them implements with basic types
• second implements with wrapped types

And it turns out that in some cases described above, this behavior changes: Just because I changed ulong to long. How to understand this logic?

I believe that either all variants of such manipulations should be prohibited, or all manipulations should be allowed.

[RioMcBoo]

Despite this inconsistency and double standards that can confuse anyone, you can try to avoid this by using constructors instead of conversion operators. But in this case it looks too cumbersome in my opinion.