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.

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

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.

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.

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.

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.

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.

2. allow any explicit double conversion for any basic type to save any logic in conversion rules.

• i meant literally doubled conversion , not related to "double" type of data.

As you can see - we even cannot make a point is that is good in this case or not. That because i related to human logic of it.

In stack overflow i reported about my current technician problem with my custom time-data conversions , i could not explain what happened there and asked about it.

So she found in IL code the fact about narrowing long to int and created this theme.

All this time i tried to imagine the root problem of it and find some human logic to legit it. But it is really looks like a bug or something.

And i really sory about my aggressive manner of speaking, this is because my native language is Russian. The entire style of this language based on emotional expression. And when i try to be neutral - i find my own thoughts were not be translated as i wanted or i must broke my mind.

Maybe it is just lack of softskills, i cannot fix myself

@RioMcBoo - the following code compiles because of the allowed ulong to uint narrowing - an extra cast (of course one that did work not just going default) could allow ulong to work, as per the examples above .. but unless you have long, uint, and int - you'll get one of ulong and long to break

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

public class C
{
    public UnixTime M(ulong i) => (UnixTime)i; // via uint
    public UnixTime M(long i) => (UnixTime)i; // This cast now fails as ambiguous
}

uint to ulong is an [allowed converstion](https://github.com/dotnet/csharpstandard/blob/draft-v8/standard/conversions.md#1023-implicit-numeric-conversions)

i agree that the surprise narrowing with no warning is surprising ...

@RioMcBoo - would option 3, working, be to add a uint option here - you can't express time in the past, but if you know you are talking about "now-ish" times, then that would be fine:

public static explicit operator UnixTime(uint i) => default; 
uint to ulong is an [allowed converstion](https://github.com/dotnet/csharpstandard/blob/draft-v8/standard/conversions.md#1023-implicit-numeric-conversions)

Could you provide more info? i didn't catch what past\future time you wrote about.

And i didn't find any possible cases when hardcoding explicit operator to return "0" could help to avoid some errors instead of make them.

Anyway, my point of interest is making clear rule of conversions and avoiding mistakes, not finding some solution to manage current problem with my custom time-data types. I could manage with that issue, i just wanted to make a signal about something in C# goes wrong .

@RioMcBoo - the following code compiles because of the allowed ulong to uint narrowing - an extra cast (of course one that did work not just going default) could allow ulong to work, as per the examples above .. but unless you have long, uint, and int - you'll get one of ulong and long to break

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

public class C
{
    public UnixTime M(ulong i) => (UnixTime)i; // via uint
    public UnixTime M(long i) => (UnixTime)i; // This cast now fails as ambiguous
}

uint to ulong is an [allowed converstion](https://github.com/dotnet/csharpstandard/blob/draft-v8/standard/conversions.md#1023-implicit-numeric-conversions)

i agree that the surprise narrowing with no warning is surprising ...

public struct UnixTime
{
    private ticks;
    public UnixTime(int i) { ticks = i; }

    public static implicit operator int(long i) => (int)i; // 1st implicit conversion

    public static explicit operator UnixTime(int i) => new UnixTime(i); // 2nd implicit converion (explicit counts as implicit in that case)


}

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

When i wrote about doubled conversion I meant these:

1. long->int
2. int->UnixTime

If both of implicit conversions is implemented - it should work. In other cases - trow error.

How it works now:

1. sometimes goes automatically without any implementation and avoid base implicit conversions rules.
2. goes well

Very these two steps i called "double conversion".

And first time i thought it was related to implicit int->single \ long-> single conversions. But i was wrong, especially because it would be triple conversion when compiler has ambiguous behaviour. But also i provided couple cases when this logic was wrong. See above.

Notes:
I wrote from my phone and cant check my examples. I can be wrong about triple implicit conversion cause to ambiguous errors. Maybe it works with double implicit conversion. In that case we must have only one implemented implicit conversion and one explicit one to allow compiling. Anyway explicit conversion counts as implicit so i changed my post due to this note.

Maybe it is just lack of softskills, i cannot fix myself

It is heartwarming to hear someone share such poignant self-reflection! If I may, I would also offer encouragement. You're exactly right that you can't fix yourself, and the good news is you don't need to fix yourself! The lack of softskills is not "you," and so there is no "self" to worry about fixing. Through merely being aware, the transformation is already in progress. Happy journeying!