Links to extensions with type parameters

[vmishenev]

fun <T : Number> List<T>.foo() {}

interface MyListWithT<T> : List<T>

interface MyListWithTNumberBound<T : Number> : List<T>

interface MyListWithNumber : List<Number>

/**
 * 1 [List.foo]
 * 2 [MutableList.foo]
 * 3 [MyListWithT.foo]
 * 4 [MyListWithTNumberBound.foo]
 * 5 [MyListWithNumber.foo]
 */
fun usage() {}

In K1 - 1, 4 and 5 are resolved, but 2 and 3 are not. In K2 the easiest solution is implemented (without type inference) that resolves only 1.

Which references should be resolved?

---

This question has come from the review of https://youtrack.jetbrains.com/issue/KT-62695

can’t we approximate the type parameter’s type with its upper bound? This question is legal, of course Let’s look at some example:

fun <T : Number> List<T>.foo() {}

/**

• [List.foo] */ fun usage() {}

  
  > If we take the `List` type and approximate it to `List<*>`, and `List<T>` to `List<Number>`, then we already have a problem: `List<*>` is not a subtype of `List<Number>`, so we should not resolve the `foo` extension at this point.
  But K1 implementation resolves that. That’s why my type comparison method does a simple equality check without any type bound
  Moving on to the next example:
  ```kt
  fun <T : Number> List<T>.foo() {}

interface MyListWithT : List

interface MyListWithTNumberBound : List

interface MyListWithNumber : List

/**

• [MyListWithT.foo]
• [MyListWithTNumberBound.foo]
• [MyListWithNumber.foo] */ fun usage() {}

  
  > K1 does not resolve the first function, but it does not resolve the first one
  The question is - why? You can still call `MyListWithT<Int>().foo()` if you want to in your code. The fact that it does not have the correct bound does not imply that it is not possible to call `foo` on the receiver of that type. At the same time, it has some contradiction with the first example - why do we resolve `List.foo`, but do not resolve `MyListWithT.foo`? `List` also does not have a proper type bound
  I was trying to draw some meaningful system from the K1 behaviour (to be fair, I didn’t look into the implementation - only on the behaviour). I also anticipated the behaviour that you’ve proposed
  However, more complicated nature of the K1 behavior got me thinking about the lack of specification for that part. I decided not to try and replicate all the details of K1 implementation without knowing at least with some certainty that this is indeed correct and desired behaviour
  So my plan was to throw in some simple, non contrived implementation which is as simple as possible while still being useful, and modify it in the future as the specification becomes more fleshed out (edited) 

[IgnatBeresnev]

Blocking?

• Testing: no
• Beta: no
• Release: No

The specification around this should be discussed to make a decision.

[whyoleg]

Proposed expected behaviour could be found in KEEP: https://github.com/Kotlin/KEEP/blob/kdoc/extension-links/proposals/kdoc/links-to-extensions.md