Why User-Defined Conversion Operators from Base to Derived are not allowed on the Derived type?

[fitdev]

class Base { }

class Derived<T> : Base {
  public static implicit operator Derived<T>(Base it) { ... } // <= Compiler Error CS0553: user-defined conversions to or from a base type are not allowed
}

It is perfectly understandable why derived-to-base would be disallowed, after all it is already part of a runtime. But why would base-to-derived be disallowed too?

Also note that it is important to define such conversions in the derived type, not the base, because:

• Base type may exist in another assembly or not be under control of a user at all
• Derived class may have type parameters, which the base class does not, as in the example

[svick]

It is perfectly understandable why derived-to-base would be disallowed, after all it is already part of a runtime. But why would base-to-derived be disallowed too?

I believe it's a similar reason: casting from base to derived already has a meaning in the language as a type test. It would be really confusing if such a cast sometimes behaved differently, so the language does not allow it.

[jnm2]

So it will not call the op_Implicit method, and instead it will (implicitly) crash with InvalidCastException if the Base was Derived<SomeOtherT>?

[BlinD-HuNTeR]

So it will not call the op_Implicit method, and instead it will (implicitly) crash with InvalidCastException if the Base was Derived<SomeOtherT>?

It will call op_Implicit if you do it implicitly (Derived<T> obj = instanceOfBase). If, however, you try to do an explicit cast (Derived<T> obj = (Derived<T>)instanceOfBase), then it will emit a builtin conversion, which will faill with InvalidCastException at runtime.

[CyrusNajmabadi]

what if you have both op_Implicit and op_Explicit?

[jnm2]

Nice, thanks! It's nice to know what it does (again- today). As you probably realize, I'm not trying to take away nice things from you per se, but pointing to likely outcomes for using it. If those two things seem equivalent to you, I'll let you sort that out. 😉

[BlinD-HuNTeR]

what if you have both op_Implicit and op_Explicit?

The immediate answer is, that op_Explicit cannot win over the built-in conversion already existing in the language, so it will be ignored. But, things can get more complex when chains are involved (casting from C to A through a base class B, that could even be object).

However none of this is unpredictable, the actual rules are those that apply when generics are involved. Take the example:

class MyClass<T> { public static implicit operator MyClass<T>(T t) { ... } }

If you have a variable or property of type MyClass<object>, then it will be implicitly castable from object, which means that it's also implicitly castable from literally anything, except interfaces.

And the point is, if such implicit conversion works with generics, then it will also work if you make MyClass non-generic, and write the conversion as [SpecialName] public static MyClass op_Implicit(object obj) { ... }. This will be a non-generic class that's implicitly castable from object.

I'm not trying to take away nice things from you per se, but pointing to likely outcomes for using it

No problem, I have years of experience of doing undocumented/unsupported/undefined behavior things, and I understand the implications. I acknowledge that none of this is officially supported, but I don't see any risks for this specific case.

The point is, Roslyn doesn't make any distinction between generics and non-generics, it has a well-defined algorithm to find user-defined conversions, and if the conversion exists, it will be used, regardless of being generic or not. And unless someone explicitly makes a change to make Roslyn ignore these "hacked" conversions, they will not stop working in the future.