Kotlin除上界外是否支持或计划支持其他泛型约束？（排除类型类）

Great question! The Kotlin docs do focus heavily on upper bounds, but there are a few other constraint types you can use today, plus some interesting plans for future enhancements. Let's dive in:

Currently Supported Constraints #

Multiple Upper Bounds #

You can enforce that a type parameter conforms to multiple types using the where clause. This is super useful when you need a type to implement several interfaces (or extend a class and implement interfaces—though remember Kotlin doesn’t allow multiple class inheritance, so only one class can be part of the bounds).

Example:

fun <T> processContent(content: T) where T : CharSequence, T : Serializable {
    // We can safely call CharSequence methods and serialize the content
    println(content.length)
    saveToFile(JSON.stringify(content))
}

Use-Site Variance Bounds #

While these aren’t declaration-site constraints on the type parameter itself, Kotlin lets you specify upper (out) and lower (in) bounds when using generic types. These control how the generic can be used in a specific context:

• out T: Treats the generic as a "producer" of T—you can only read values of type T from it. This lets you assign a subtype collection to a supertype variable (like List<String> → List<out Any>).
• in T: Treats the generic as a "consumer" of T—you can only write values of type T to it. This lets you assign a supertype collection to a subtype variable (like MutableList<Any> → MutableList<in String>).

Example of use-site variance in action:

fun transferData(source: List<out Int>, destination: MutableList<in Int>) {
    destination.addAll(source)
}

Future Enhancements #

As of Kotlin 1.9, the language team is exploring a few ways to expand generic constraints:

• Declaration-Site Lower Bounds: Right now, lower bounds only work at use-site. There’s an active proposal to let you declare lower bounds directly in a generic type’s definition, which would simplify patterns where you need a type parameter to be a supertype of another type.
• Value Class-Specific Constraints: With value classes becoming more widely used, there’s work to add constraints that restrict type parameters to value classes exclusively. This would unlock optimizations tailored to value types, like avoiding unnecessary boxing.
• Granular Variance Controls: Discussions are ongoing about more flexible variance rules, such as combining variance annotations with other constraints to make generic code safer and more expressive.

For the latest updates, keep an eye on the Kotlin KEEP repository where language proposals are discussed and finalized.

内容的提问来源于stack exchange，提问作者Alexey Romanov