Implicit conversion/cast operators from interface types

[Unknown6656]

During some code developement today, I wanted to write something like this:

public class MySpecialCollection
    : IEnumerable<double>
{
    // ...

    public static implicit operator MySpecialCollection(IEnumerable<double> values) => ....;
}

to allow some user code like the following:

void Main()
{
    MySpecialCollection coll1 = ...;
    MySpecialCollection coll2 = from double d in coll1
                                ...
                                select d + 42.0;
}

Obviously, the code would not compile:

CS0552: 'MySpecialCollection.implicit operator MySpecialCollection(IEnumerable)': user-defined conversions to or from an interface are not allowed.

Aside from wanting this code to work, it got me thinking:
Why did Microsoft take this design choice at that time? What were the specific reasons? I hardly think that it was an CLR-issue, as operators get compiled to (specially named) methods in the background -- so any conversion operator invocation should work exactly like an equivalent static method invocation.

Bonus points if you are a member on the LDT and you can tell me whether the team would be open to relaxing this conversion rule/limitation.

[YairHalberstadt]

https://stackoverflow.com/questions/2433204/why-cant-i-use-interface-with-explicit-operator

User-defined conversions are not allowed to convert from or to interface-types. In particular, this restriction ensures that no user-defined transformations occur when converting to an interface-type, and that a conversion to an interface-type succeeds only if the object being converted actually implements the specified interface-type.

[raducoriu]

That only addressed the to conversion, not the from conversion for which I have not found any satisfactory explanation to.

[CyrusNajmabadi]

That only addressed the to conversion, not the from conversion for which I have not found any satisfactory explanation to.

We've answered that in this discussion already. :-)

[raducoriu]

We've answered that in this discussion already. :-)

You didn't, not satisfactory anyways. It's a completely artificial limitation and your only argument was that it's "strange"

[CyrusNajmabadi]

It's a completely artificial limitation

All limitations are artificial. This one is intentional, with the reasoning given for why we do not want to allow it.

[Unknown6656]

Oh, well that is more than understandable.
Thank you!

EDIT: On second thoughts, however, it is understandable when converting to an interface.
The other way around (e.g. like in my original post) does not make to much sense in my opinion......

[huoyaoyuan]

The recommended usage of conversion in linq is an explicit ToXXX extension method, like ToArray, ToList, ToHashSet.

[viliml]

But what about generic wrapper classes with an implicit conversion operator from the wrapped type? They work when the type argument is a class but inexplicably break when it's an interface. This violates the principle of least surprise.

[333fred]

Oh, well that is more than understandable.
Thank you!

EDIT: On second thoughts, however, it is understandable when converting to an interface.
The other way around (e.g. like in my original post) does not make to much sense in my opinion......

That would be odd for the same reason: you just converted a thing from an interface type, yet you cannot go back to that interface?

I i = ...;
C c = i;
Console.WriteLine(c is I); // Never returns false today (Assuming I is an interface) 

[ghost]

Hi, ran into CS0552 recently, hope it's ok if I bump this discussion.

That would be odd for the same reason: you just converted a thing from an interface type, yet you cannot go back to that interface?

Since one-way conversions are already a thing

class A { public static implicit operator A(B b) => ... }
class B {  }

A a = new B();
Console.WriteLine(a is B); // always false

what motivates the special treatment for conversions from interfaces?

[DerekR15]

Not only are one-way conversions already a thing, per "ghost's" answer above, but we can also already convert from an Interface (sort of) when employing generics:

interface I { }
class C : I { }
C c = new C();

// Case 1:
class A { public static implicit operator A(I i) => new(); } // Not allowed (CS0552)
A a = c; // Will not work. Need to replace "I" with "C" above.

// Case 2:
class B<T> { public static implicit operator B<T>(T t) => new(); }
B<I> b = c; // Works.

In Case 2, the T in implicit operator B<T>(T t) is effectively an interface I due to the generic B<I>, but the compiler allows it, so we can effectively convert from anything that implements I.

Granted, the compiler does disallow converting from I directly, so this does not work:

// Case 3:
I i = new C();
B<I> b2 = i; // Not allowed (CS0266)

But Case 2 demonstrates that the language does allow user-defined interface-based conversions.

So, one-way conversions are already a thing, and implicit conversions from an interface type are already a thing (in a roundabout way). But directly defining conversions from an interface is disallowed for some arbitrary reason.

Personally, the reason I want this is so I can define an implicit conversion from an IEnumerable<T> to my custom collection class. I just can't see why defining a conversion from T[] is allowed but defining one from IEnumberable<T> is not.

[CyrusNajmabadi]

I just can't see why defining a conversion from T[] is allowed but defining one from IEnumberable is not.

Because in the former case an existing conversion could not exist, while in the latter case it would. Leading to a strange situation where we'd pick the user defined conversion, not the real conversion.

[aradalvand]

All of the arguments provided here in support of this highly arbitrary and profoundly unnecessary limitation are nonsensical, as comprehensively demonstrated by @DerekR15.

Indisputably terrible decision.

[nth-commit]

I always bump into this, it's so annoying.

Can we get any answer from the team as to why this can't be disabled?

[CyrusNajmabadi]

As an example: #3464 (reply in thread)

another commenter summed it up quite well, as "the principle of least surprise".

It would be very surprising to me. For example, it would now mean that a cast to an interface would go through different dispatch, even if the object in question actually implemented the interface. You could even get a disparate instance.

Imagine the following: x is IFoo is true, but then casting to IFoo gives you a different instance.

I don't think this is a good way to express the argument to a user.

Whether or not it is good, it is the reality of things. Changes to it need justification. And those justifications need to be very compelling, especially when they would allow something that many here (myself included) find deeply problematic.

That you can get entirely different results, in entirely different code cases for this interface cast (sometimes it will be the static call to the operator, somtimes it will be a runtime check), and the same object may end up having two disparate cast paths for the same interface type, is something unpalatable.

You may disagree. You're welcome to. But at that point, absent a highly compelling reason to change this, it won't change.

[CyrusNajmabadi]

but I can't see any decent explanation of why a conversion from an interface is not allowed. Not allowing conversion to an interface makes sense to me.

The same reasons hold for both. Say we did allow you to convert from an interface to a concrete type.

Then the concrete type actually ends up implementing the interface. This can trivially happen in multiple ways (both with and without recompiling code). For example, the concrete type you reference may end up releasing a new version of the lib it is in where it now implements that interface. Now the cast is not properly going through the runtime's downcasting, but through this static dispatch.

However, you dont' even need to recompile for this to happen. Here's a trivial example of why it would be bad:

interface IFoo
{
}

class C
{
}

// This may not even be in any source code you see.  it can be in 
// an entirely different assembly, provided at runtime.
class CFoo : C, IFoo
{
}

If you have this and you have an instance of 'C', you don't actually know if it implement that interface (nothing about it indicates as such). however, if you have:

void G(IFoo f)
{
    C c = (C)f;
}

Then having this call through a static operator would break dispatch entirely in the case where f is actually an instance of CFoo.

[CyrusNajmabadi]

I often bump up against this when I'm doing otherwise completely sane refactors. For example, I have a class that's used around my codebase, and for any reason, I might want to convert that class to an interface. I extract the interface and replace references to the class everywhere, and now the code doesn't compile because the class was used in an explicit conversion.

This is only a sane refactor if certain things hold true for your codebase. They may not hold true of all codebases. In your case, you have an explicit conversion which is safe, but which now may be unsafe now that you have an interface. Why? Because of the reasons shown above. You may have an actual instance that should be a normal runtime downcast to the concrete type. But instead of performing that, you are hijacking and going through a static dispatch to some conversion method.

Note that these are not hypothetical scenarios. Having subclasses actually provide interface impl on types that otherwise have no relation to the interface is a normal and common coding pattern. It may not exist in your codebase for these types and interfaces. However, these concerns and rules exist for the broader ecosystem where that is a real thing, and which we believe needs to have very specific runtime type checking and casting semantics.

[colejohnson66]

Imagine the following: x is IFoo is true, but then casting to IFoo gives you a different instance.

Isn't that already possible, somewhat? someT1 is T2 can be false, while T2 someT2 = someT1 works. While the arguments make sense to me, it feels a bit thorny considering user-defined casts already exist. Why is T2 someT2 = someT1 ok unless T1 is an interface?

[lgarczyn]

One other benefits of allowing this would to enforce cast operators in generic arguments, and even provide default implementation for them

interface IToInt
{
  static abstract explicit operator int(ToInt i);
}

class A<T>
where T: IToInt
{
  public int ToInt()
  {
    return (int)(T)default;
  }
}