Nested (non-capturing) type aliases

[serras]

This is an issue to discuss nested (non-capturing) type aliases. The current full text of the proposal can be found here.

Right now type aliases can only be used at the top level. The goal of this document is to propose a design to allow them within other classifiers, in case they do not capture any type parameters of the enclosing declaration.

[revonateB0T]

I personally think this proposal is trivial and nothing to discuss(in design)(I support it, certainly).
Btw, sorry for the off-topic, @serras now that you mentioned them and you are in Jetbrains Kotlin team,

Going even further than capture, it is a non-goal of this KEEP to provide abstraction capabilities over type aliases, like abstract type members in Scala or associated type synonyms in Haskell. Roughly speaking, this would entail declaring a type alias without its right-hand side in an interface or abstract class, and "overriding" it in an implementing class.

interface Collection {
   typealias Element
}

interface List<T>: Collection {
   typealias Element = T
}

interface IntArray: Collection {
   typealias Element = Int
}

Will kotlin support these language features(i.e. capturing type alias, abstract type members, associated type synonyms, or let's say further, dependent functions) in future?

[serras]

Will kotlin support these language features?

I cannot say for sure, although I highly doubt that anything resembling type-level computation would make it into the language. The only exception is many capturing type aliases (you can even see that the first iterations of the proposal in the Git history had those), but there are interesting questions like how would instantiation work for things like:

class Example<T> {
  inner typealias A = List<T>
}

Should one require an instance of A to call the List constructor? How does it relate to things like listOf? Because of those questions we've decided to go first with the obviously useful feature (non-capturing type aliases) and then move to capturing type aliases if needed.