instantiateToBounds sometimes fails to eliminate type parameters

[stereotype441]

When the following code snippet is analyzed in strong mode:

    class C<T extends C<T, U>, U extends num> {}
    C x;

The type of x is being instantiated to C<C<dynamic, U>, num>. This can't be right, since U is not in scope at the site of the declaration of x.

Reading through the code for StrongTypeSystemImpl.instantiateToBounds, it's not clear to me what the intended behavior is.

Note that if the order of generic args is reversed, i.e.:

    class C<S extends num, T extends C<S, T>> {}
    C x;

the type of x is instantiated to C<num, C<num, dynamic>>.

[jmesserly]

ah it's a recursive bound. in general we don't handle those very well in strong mode.

[jmesserly]

Oh shoot. We had an (apparently incorrect) assumption that earlier type parameter bounds did not depend on later type parameters. But here the bound on T depends on U. Thoughts @leafpetersen ?

[leafpetersen]

I had in mind that the F-bounded subtyping for strong mode would be ordered, rather than mutually recursive, in which case the initial example is broken code and should get an error.

This might be too restrictive - I'd like to consider supporting mutually recursive bounds. It covers some useful cases.

I also think I need to rethink the implicit instantiation logic - I am leaning towards just not allowing implicit instantiation for things with f-bounds. The answer you get there is almost never what you want.

[jmesserly]

I also think I need to rethink the implicit instantiation logic - I am leaning towards just not allowing implicit instantiation for things with f-bounds. The answer you get there is almost never what you want.

yeah, great idea.

another place this comes up is generic functions/methods, when the upper bounds can be the best result we get out of inference. Would we want to also disable inference in those cases?

[leafpetersen]

Yeah, at least in the f-bounded case, I'm thinking that we should probably just ignore the bounds for inference. We could think about how to use them, but in general I don't think we can do so usefully. We may want to use them in the non-f-bounded case, but I think it's pretty marginal benefit.

[MichaelRFairhurst]

Question came to mind.

How is this being handled for cases like class Enum<E extends Enum<E>>?

In the case where you extend it you have to resolve the circular nature, ie, class IntEnum extends Enum<IntEnum>, but in this case the correct behavior as far as I can tell is to construct the infinite type Enum<Enum<Enum<Enum<Enum....

Maybe the correct behavior is to detect this and report that it cannot be instantiated without specifying the type parameters because they would be infinite. Or maybe the infinite nature could be handled with some tricky algorithms.

[jmesserly]

that's a really good question :D. There's a lot of discussion over in this issue: #27526

edit: the short answer is it would be an error if a default cannot be computed.

[leafpetersen]

This is now fixed.