Implicit conversion of Some / Option SubTypes about language-ext

[louthy]

The problem is that struct doesn't support covariance. So there's no easy fix for this.

For example this below won't work:

        public static void Foo(Some<IEnumerable<string>> val)
        {
        }

        public void SomeCastTest1()
        {
            var some = new Some<List<string>>(new List<string>() { "a", "b", "c" });
            Foo(some);
        }

But this will:

        public void SomeCastTest2()
        {
            Foo(new List<string>() { "a", "b", "c" });
        }

So you could either not pass Some<T> into functions, and only use them to protect function parameters. Or, you could manually extract the .Value

        public void SomeCastTes3()
        {
            var some = new Some<List<string>>(new List<string>() { "a", "b", "c" });
            Foo(some.Value);
        }

Or you could implement your own cast method:

        public static Some<R> Cast<T, R>(Some<T> value) where T : R =>
            value.Value;

The problem with that is the type-inference system is poor in c# so you end up with lots of type boilerplate:

            Foo(Cast<List<string>,IEnumerable<string>>(some));

So unfortunately there aren't any perfect solutions here.

[donners77]

Hi.

I think I've tried what you suggested...

    public void SomeCastTes3()
    {
        var some = new Some<List<string>>(new List<string>() { "a", "b", "c" });
        Foo(some.Value);
    }

But it doesn't seem to be acceptable to the compiler...

[donners77]

I think I may have found a solution...

public static Some<T> ToSome<T>(this T value) { return Create(value); }

Then to fix the error in the previous screenshot I can do filterMut.Value.ToSome<IFilter<T>>() in c# 5, which is not too messy.

[donners77]

The implicit type conversion also seems to fail at times when no unwrapping is required, e.g...

ToImmutable() returns an IFilterIm<T> but the compiler complains about implicitly converting this to a Some<IFilterIm<T>>

I wonder if this is some implicit casting limitation related to Generics?

However, using the static ToSome() method I proposed above without any type annotation makes it acceptable to the compiler.

[donners77]

Hi. Wondering if you have any further thoughts on this?

[louthy]

Hi @donners77 ,

If I'm honest I haven't spent too much time thinking about it, no. I'd be slightly reluctant to add ToSome() as an extension method to T, mainly because it then pollutes the intellisense for everything, and I think that's a bit too much of an intrusion by a library, especially for those who don't use the Some<T> type, but are using other aspects of the library.

Obviously ToSome() works because it's not doing implicit type casting of a T to a Some<T>, it's passing a T to the constructor of Some<T> where the implicit type casting of T happens. Until struct can do covariant implicit type-casting I think you're stuck with ToSome() as a solution. You'll just need to create it yourself.

I guess one way could be to put the extension method into its own namespace. Perhaps LanguageExt.SomeHelp. That would mean you could opt into it. I guess I'd be amenable to this idea. What do you think?

[donners77]

Hi. I don't mind. Happy to just implement it for myself. Happy for it to be in the namespace you suggested if you think other people will need it.

[louthy]

Cool, I've now added this to the LanguageExt.SomeHelp namespace. Thanks for the suggestion :)