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

[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]

[jilles-sg]

The confusing behaviour follows the specification at https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/language-specification/conversions#1055-user-defined-explicit-conversions . The idea appears to be that a standard explicit conversion can be inserted both before and after a user-defined explicit conversion operator, but the types should not be "too unrelated" due to the part "Find the set of applicable user-defined and lifted conversion operators". So casting a long to UnixTime works because there is an implicit conversion from int to long and an explicit conversion from long to int, but casting an ulong to UnixTime does not work because there are no implicit conversions between int and ulong in either direction.

I suggest defining the conversion from int to UnixTime as an extension method, which provides both the requested type-safety and readable left-to-right operation. The conversion from UnixTime to DateTime can be an instance method.

By the way, 2038 is less than 13 years away, so long would be a better underlying type for UnixTime.

[RioMcBoo]

I deleted my old misleading messages and added new correct descriptions (please look this thread again)

[RioMcBoo]

I think many people don't understand what I'm talking about. The first message in this discussion gave an example that doesn't directly address the current problem.

And I think no one read my messages carefully after that and jumped to conclusions automatically, not realizing the problem.

Now I'll redo this example, and you'll finally understand what I was trying to convey.

A brief background: I asked a question on the StackOverFlow forum, and a girl confirmed that she thought there was a problem. And I really thought that this was the problem. She created this thread and gave me a link to it. So, all the discussion remained behind the scenes, except for her message, which doesn't address the essence of the problem. Simply because if the C# analyzer behaved consistently and identically for all data types, I would have guessed myself that these are the rules of explicit type conversion.
But C# behaves differently depending on the types.
Look at the following example.

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

public class C
{
    public UnixTime Method(ulong i) =>
        (UnixTime)i;    // type narrowing (ulong -> int) not allowed

    public UnixTime Method(long i) =>
        (UnixTime)i;    // type narrowing (long -> int) allowed
}

Now you can clearly see that the example in the first message does indeed work according to the language rules. I used an explicit conversion, knowing it was a narrowing type, which meant I was accepting the loss of data (long -> int).

But from another perspective, if I perform the exact same explicit conversion and also agree to a type narrowing (ulong -> int), C# assumes that even though I used an explicit conversion, I must adhere to the type specification. (And this, in my opinion, is correct, because that's what strong typing is for, and explicit conversion for base types works as in the first case because the operator actually calls overloaded functions for the specific base type and the target base type.)

[RioMcBoo]

That's the problem, in my opinion. I described the issue broadly. Reporting bugs separately for each type and each case won't be obvious, nor will it be clear how these issues are interconnected.

It's better to simply rename this discussion to something else that can more broadly describe what's going wrong.

Besides, I don't like the very approach of trying to conform to some specification.

This way, you can describe all the bugs in the specification and say they're not bugs, but intended that way.

It's very disappointing that this issue is being held back due to the need to maintain already compiled code.

I'd like to see a new version of the compiler in the future that will fix known bugs, with the ability to select the version in the settings for new projects, so as not to depend on legacy code.

[RioMcBoo]

I mean that the specification corresponds to reality, not that reality should correspond to the specification.
For example, I don't understand why C# allows conversion from long to double/float/etc., losing data in the process. Even if it's described in the specification, we need to ask why it was done in the first place if it doesn't align with common sense. It was probably originally done by mistake, and then added to the specification to legitimize this behavior.

[jnm2]

My thought was to give you the best chance of being heard out, since you're coming with a request for a language change, whereas this thread thus far has not been about requesting a language change. It was a clear report that the compiler didn't match the spec, with the clear resolution that it actually does match the spec. Starting with a clean slate will prevent every reader from starting at the top and misunderstanding what the whole thread is about, and I don't really see the downside to giving yourself that clarity. However if you would rather ignore this and take your chances at redefining the thread, I hope it works for you!

We can do both things at once: both keep a compiler conforming to a specification, and evolve that specification forward. In practice, these goals don't end up in conflict. It's good to be clear on what the specification actually says before proposing changes to it. I don't see a way in which your issue is being held back; in fact, my goal was to get your issue moving by suggesting starting a new thread.

[RioMcBoo]

If you know how to do this (in which project branch, with what tags, and how to name it correctly), I'd ask you to take on this burden, as my understanding of the compiler's internals is limited, and my English is also poor. All my attempts to provide feedback are usually misunderstood, or I'm doing it incorrectly.

Even now. It looks like some guy off the street has decided to change the way C# works globally. It seems very audacious, but deep down, I know it shouldn't work this way.

I merely pointed out the location, the symptoms of the problem. Perhaps the problem is much deeper, and if specialists look into it, they'll fix it globally, not just for the long type.

I deleted the post (you can perhaps view the history) where I listed all the types that experience the same issue. It's wrong, in my opinion, to only address the reported issues and ignore the underlying problem.

So, if I create a new topic and describe the entire list of types this happens to, but I forget one type through mistake or carelessness, will you correct all the types except the one I forgot?

I can't understand how this machine called "corporation" works.

[jnm2]

I would recommend starting a thread in the Discussion section of this repository, with the category Language Ideas, with a title that describes the underlying problem itself, as you see it, which contains a few concrete examples, just enough to illustrate the range of the underlying problem, and which speaks to the concrete upsides of fixing the problem.

Be ready for community members to weigh in who want to explore alternatives or to confirm why it's actually worth doing. This is a normal part of our community here. If the idea is really a good idea for the whole community, the path to getting traction is to engage with all the exploration- the questions, concerns, and brainstorming, with a "yes, and" mentality. You don't have to be the one to carry it forward, you can respond or not with as much or as little time or energy as you want to put in.

Yeah, corporations can be a weird phenomenon, right? If it helps to know, I'm a community member outside of Microsoft and I'm volunteering my spare time to help move your ideas forward.

[jnm2]

This is not a compiler bug, but is how explicit conversions have been specified since C# version 1.

I'm a little confused about what the intuition is for the spec to apply a standard implicit conversion (int to long) in reverse during an explicit conversion, while not applying standard explicit conversions such as ulong to int. I'm curious if anyone has an intuition for what the spec is doing here.

Walkthrough

This is the reported sample:

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

public class C
{
    public UnixTime M(long i) => (UnixTime)i; // This cast should fail to compile, but it compiles successfully.
}

(UnixTime)i is a user-defined implicit conversion. §10.5.5 User-defined explicit conversions defines how this is processed.

A user-defined implicit conversion from an expression E to a type T is processed as follows:

E is i and T is UnixTime.

• Determine the types S, S₀ and T₀.
  • If E has a type, let S be that type.

i has the type long, so S is long.

• If S or T are nullable value types, let Sᵢ and Tᵢ be their underlying types, otherwise let Sᵢ and Tᵢ be S and T, respectively.
• If Sᵢ or Tᵢ are type parameters, let S₀ and T₀ be their effective base classes, otherwise let S₀ and T₀ be Sᵢ and Tᵢ, respectively.

These special cases don't apply; S₀ remains long and T₀ remains UnixTime.

• Find the set of types, D, from which user-defined conversion operators will be considered. This set consists of S₀ (if S₀ exists and is a class or struct), the base classes of S₀ (if S₀ exists and is a class), T₀ (if T₀ is a class or struct), and the base classes of T₀ (if T₀ is a class). A type is added to the set D only if an identity conversion to another type already included in the set doesn’t exist.

The set of types D thus consists of long and UnixTime.

• Find the set of applicable user-defined and lifted conversion operators, U. This set consists of the user-defined and lifted implicit or explicit conversion operators declared by the classes or structs in D that convert from a type encompassing E or encompassed by S (if it exists) to a type encompassing or encompassed by T. If U is empty, the conversion is undefined and a compile-time error occurs.

According to this step, the compiler must include in U the user-defined conversion operator UnixTime(int i), because it converts from a type (int) which is encompassed by S (type long).

"Encompassing" is defined in §10.5.3 Evaluation of user-defined conversions:

• If a standard implicit conversion (§10.4.2) exists from an expression E to a type B, and if neither B nor the type of E (if it has one) are interface_types, then E is said to be encompassed by B, and B is said to encompass E.

Because there is a standard implicit conversion from the type int to the type long, the type long encompasses the type int. The user-defined conversion operator in the sample converts from int, which is a type that is encompassed by S, so the user-defined conversion operator is included in set U, rather than being excluded as the original post expected.

(This is the point at which the algorithm would diverge for ulong. ulong does not encompass int because there is no implicit conversion from int to ulong. This is because ulong cannot represent negative int values. For an S of ulong rather than long, the algorithm would terminate here with an empty U causing a compile-time error.)