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.