REQUEST: Pattern matching/better type inferencing with generics.

[TonyValenti]

Hi Roslyn Team:
When I was reading one of the feature requests from earlier:
#2212 (comment)

It made me think of something I have really been wanting as of late:

Pattern matching/better type inferencing with generics.

Today I can write code like this:

        private static void Foo<T, X>(T Object) where T : IEnumerable<X>, IComparable<X> {
            //Do Something
        }

        private class MyClass : IComparable<String>, IEnumerable<String> {
            int IComparable<string>.CompareTo(string other) {
                throw new NotImplementedException();
            }

            IEnumerator IEnumerable.GetEnumerator() {
                throw new NotImplementedException();
            }

            IEnumerator<string> IEnumerable<string>.GetEnumerator() {
                throw new NotImplementedException();
            }
        }

        private static void CallMyFunction() {
            var C = new MyClass();

            Foo<MyClass, String>(C);
        }

There is nastiness is in how I have to call the function.

        private static void CallMyFunction() {
            var C = new MyClass();

            Foo<MyClass, String>(C);
        }

In this example, I feel as though Foo should automatically figure out the type parameters and I should be able to call the method as follows:

        private static void CallMyFunction() {
            var C = new MyClass();

            Foo(C);
        }

[gafter]

It sounds like you want the bounds of type variables to participate in type inference. I can see us taking such a well-specified and prototyped change.

[TonyValenti]

That sounds great! This will make my code so much cleaner. Thank you!

On Sunday, September 6, 2015, Neal Gafter notifications@github.com wrote:

It sounds like you want the bounds of type variables to participate in
type inference. I can see us taking such a well-specified and prototyped
change.

—
Reply to this email directly or view it on GitHub
#5023 (comment).

Tony Valenti

[gafter]

@TonyValenti I've labeled this "up for grabs" in case someone from the community has the time and interest to take it on.

[HellBrick]

I think I might be able to take a shot at this. I'm currently toying with a prototype of this that works by promoting generic constraints of inferred type parameters to fake arguments. The idea is to add a 4th step to the phase 2 of the inference that works this way:

1. For every constraint type of every type parameter that has been successfully fixed a new fake argument is added. The fixed type is used as an argument type, its default value is passed as an argument expression and the formal argument type is set to the constraint type. This is done no more than once per type parameter.
2. Phase 1 is invoked for the newly added arguments.
3. Phase 2 body is considered to make some progress if any constraints were promoted, and is considered to make no progress otherwise.

Here's an example to illustrate the idea:

    class Item : IComparable<string>
    {
    }

    class Container : IEnumerable<Item>
    {
    }

    class Whatever
    {
        void DoSomething<TContainer, TItem, TComparand>( TContainer container )
            where TContainer : IEnumerable<TItem>
            where TItem : IComparable<TComparand>
        {
        }

        void Invoke()
        {
            DoSomething( new Container() );
        }
    }

The type inferrer that exists today is able to infer that TContainer is Container and then fails. Here's what happens if the idea I've described is implemented:

• We have a type parameter TContainer that's fixed to Container. It has IEnumerable<TItem> constraint which is promoted to a fake argument like this:

    class Whatever
    {
        void DoSomething<TContainer, TItem, TComparand>( TContainer container, IEnumerable<TItem> x )
            where TContainer : IEnumerable<TItem>
            where TItem : IComparable<TComparand>
        {
        }

        void Invoke()
        {
            DoSomething( new Container(), default( Container ) );
        }
    }

• Phase 1 is invoked for the argument x, providing us bounds for TItem type.
• Phase 2 body is repeated like it typically does, fixing TItem to Item.
• Old phase 2 logic can't progress it any further, but now that TItem is fixed, we can promote its constraint like this:

    class Whatever
    {
        void DoSomething<TContainer, TItem, TComparand>( TContainer container, IEnumerable<TItem> x, IComparable<TComparand> y )
            where TContainer : IEnumerable<TItem>
            where TItem : IComparable<TComparand>
        {
        }

        void Invoke()
        {
            DoSomething( new Container(), default( Container ), default( Item ) );
        }
    }

• Phase 1 is invoked for the argument y
• Phase 2 continues its loop and is now able to fix TComparand to string
• The fake arguments obviously exist only in the type inferrer's imagination =)

---

So what do you guys think? This seems to be working for the simple scenarios it's designed for, but there's a lot of scary stuff in the type inference that I haven't even begun to understand, so it would be useful to get input from someone who has been familiar with this part of the compiler for more than a day ;)

[bbarry]

I presume your phase 2 would still fail if Item were this instead:

class Item : IComparable<string>, IComparable<IEnumerable<char>>
{
}

[HellBrick]

Yep, it fails for the same reason the following fails today (because in the end it boils down to exactly the same problem):

    class Item : IComparable<string>, IComparable<IEnumerable<char>> {}
    void Compare<T>( IComparable<T> comparable ) {}

    void Call()
    {
        Compare( default(Item) );
    }

[HellBrick]

I've submitted a PR with the prototype to provide something less abstract to discuss.

[MrJul]

I know the Roslyn team is probably busy with Update 1, but it would be nice to get some feedback on @HellBrick's great PR :)

[gafter]

@HellBrick We'll take a look at this, thanks!

[gafter]

Removing "Up For Grabs" as @HellBrick has grabbed it!