Allow types with the same name at different kinds.

I’d like Scala to allow abstract and alias types with the same name but different kinds. E.g.

class C {
  type This
}
class D[A] {
  type This[X]
}
object O extends C with D {
   type This = o.type
   type This[X] = o.type
}

Benefits:

• It gives us a way to address #2887, because ill-kinded types in that issue would translate to overloaded types, so no conflicting kinds can arise.
• It could avoid namespace pollution in high-level encodings such as the encodings of type classes that we study.

The proposal would be to distinguish same-named types by their kind class, where the kind class in this case only talks about arities, but not about bounds and variances. So

type T
type T[_]
type T[_, _]
type T[_[_]]

are all in different kind classes (and therefore can be defined in the same scope), but

type T[X]
type T[+X]
type T[X <: AnyRef]

are all in the same kind class, so defining them all in the same scope gives double definition errors. The reason for this distinction is that there is no subtype relation between types in different kind classes, so we can use the kind class as a partition criterion.

One tempting generalization of this scheme is to extend it to traits and classes. E.g. where we write Function1, …, Function22 now, maybe we should allow instead:

trait Function[-T1, R] { ... }
trait Function[-T1, -T2, R] { ... }

and so on. But that one is much harder to define and implement. First, what about the companion object? Of which trait is object Function { ... } the companion? Second, what about binary names? What are the names of the Java interfaces that these Function traits map to? So for the moment, this generalization is not considered as part of this issue.

Besides, one can get a long way already with overloaded aliases. I.e. keep the definitions of the traits Function1, …, Function22 as they are now, but add aliases:

type Function[-T1, R] = Function1[T1, R]
type Function[-T1, -T2, R] = Function2[T1, T2, R]

and so on.

[sjrd]

Aren’t you constantly saying that overloading is a pain to deal with in a compiler? And now you want to add type overloading?

Also,

[…] But that one is much harder to define and implement. First, what about the companion object?

With opaque type aliases, types are about to gain companion objects too. What then?

[smarter]

Closing as I think this proposal has been abandoned, but feel free to reopen if there’s still interest.