Add ability to provide array type conversion for a type

[hawkerm]

If I create a class and give it an implicit conversion operator (in C#):

        public SomeClass(string value) 
        {
            // ...
        }

        public static implicit operator SomeClass(string value)
        {
            return new SomeClass(value);
        }

It'd be nice to also be able to provide an array converter as well, e.g.

        public static implicit operator SomeClass[](string[] values)
        {
            return values.Select(value => new SomeClass(value)).ToArray();
        }

Currently, the implicit conversion won't happen automatically for the array (even with the singular implicit converter defined); so making an extension to the other type to provide a helper seems to be the only route but a bit messier.

Also found similar questions for this process dating back to 2010 here.

It also seems like there should be something similar for VB? https://stackoverflow.com/questions/1312549/is-there-a-way-to-define-an-implicit-conversion-operator-in-vb-net

Originally filed here

[svick]

What makes arrays special? Wouldn't you also want to be to convert e.g. List<string> to List<SomeClass>? I think that would make this proposal much more powerful.

[ghost]

I just faced the same problem a few minutes ago!
But I think C# can solve this problem without adding any new syntax.
Why can't C# compiler do if for us? If array1 element type can be converted to array2 elemt type, then C# should do a little work to cast array1 to array2. This applies to all collections, lists, enumerables.... etc.

[CyrusNajmabadi]

It'd be nice to also be able to provide an array converter as well, e.g.

I would very much not like an implicit operator making a full copy of an array behind the scenes.

[CyrusNajmabadi]

Why can't C# compiler do if for us? If array1 element type can be converted to array2 elemt type, then C# should do a little work to cast array1 to array2.

C# and .net already have semantics around array conversions. They do not involve new arrays being allocated, and introducing such a feature would be a massive footgun.

This applies to all collections, lists, enumerables.... etc.

There is already .Cast<T>() in linq. you can also just write: from Whatever t in collection select t. And the compiler will call .Cast for you.

Both of these are good because it is clear from the code that you are doing some sort of implicit conversion, but are actually performing computation that could be expensive and which can produce a new collection instance. There is no need (or desire) for a language feature here when the code you can write is trivial and already provided by the framework. And that's doubly true given the huge potential problems that could come with this feature.

so making an extension to the other type to provide a helper seems to be the only route but a bit messier.

I disagree that it's message. It's a nice bit of explicit code that is easy to understand, idiomatic, and plainly calls out the cost and semantics of what are happening. That's absolutely what you want when operating on arbitrary sized pieces of data. :)

[bbascarevic]

@CyrusNajmabadi Cast<T> doesn't work for conversions. Cast<T> is defined on Enumerable which sees elements as objects, so it doesn't resolve conversion operators of the element's actual type because the type information is lost in the static context. You'd have to write conversions to/from object, which is not possible, as conversion to/from base type (i.e. object) is not allowed.

[CyrusNajmabadi]

Yes. That's a good thing here. If you want conversions, you can use .Select and do the conversion within the lambda.