Union types


I agree with 100% Java interop as well as union type is implicit. but nevertheless Kotlin.js need Union Type for JS interop. Yes, parameter of union type can be replace with method overloading but javascirpt can be return union type as follow.

interface HTMLAllCollection {
    getter (HTMLCollection or Element)? namedItem(DOMString name);

this IDL can be translate to kotlin code as follow.

public external abstract class HTMLAllCollection {
    fun item(nameOrIndex: String = definedExternally): UnionElementOrHTMLCollection?

public external @marker interface UnionElementOrHTMLCollection {

this is not easy to understand and need to type casting. but what if kotlin.js have union type can be simplify as follow. furthermore dynamic keyword can be replace by union type for explicit.

public external abstract class HTMLAllCollection {
    fun item(nameOrIndex: String = definedExternally): (Element | HTMLCollection)?


The Java interop argument regarding union types doesn’t seem consistent with coroutine design choices. You pretty much need a third party library for Kotlin coroutine features to be usable from Java code. Seems to me that there are many potential union type designs that wouldn’t be nearly as messy to call from Java as suspending code is with no additional libraries. In my opinion, it’s ok to require a third party library on the Java end to make calling some Kotlin features clean as long the Kotlin team provides this support.

Although some of the other arguments about maintainability and readability do seem valid. I don’t think simply allowing | operator in between types anywhere in the codebase is the right choice as I think it will be messy and overused.


Kotlin has already a limited form of a union types, the unbounded union type a.k.a Any.

So it would be nice to have bounded types as well.

Assume you have a function jsonfy to pack elements of Int, Float, String into a JSON value.

Then, the following is valid:


This would be tedious with Any, as all types have to be covered in order to work it out.

In fact, the advantage of union types is that methods that are available to all ingredients of it, can be applied to any value of this type.

For special purposes, one have to reflect over it as already mentioned in posts before.

For the case of java interop I would implement a Union type as class for each arity containing an element and an index ranging from zero to arity.

The index will be updated alongside of assignments made to union values.


Maybe I misunderstood something, but to me it seems that the thing you actually want is ducktyping or being able to implement interfaces for 3rd party classes. Personally, I really like how Rust solved this issue…

impl JsonValue for String {



Sorry for the late reply but I don’t get any notifications from discourse when someone writes something.

but to me it seems that the thing you actually want is ducktyping

Union typing is dynamic typing but its runtime polymorphism is bounded.

Rust can do this with existentials which may be possible in kotlin if kotlin adds typeclasses and typeclasses are first class.

But there are valid points for union type because operations which exists on all its element types are implicitly available for union types such that for a l1,l2:List<Union<Int,Float,Rational>> you can implicitly map(+,l1,l2) without to create a typeclass/trait for this.

Further, union types are structural and they subtype, does trait object sprovide the same?


@elizarov wrote:

I would actually go a step further, and instead of Pair<String, Any?> or Pair<String,JsonValue> also define JsonPair class with the convenient constructors for it, too.

The point is the a JsonValue Classis unbounded, even a Rust trait a.k.a as tyepclass is also unbounded.

@WickeDev wrote:

Yes, parameter of union type can be replace with method overloading but javascirpt can be return union type as follow

Then you could also state that subclassing replaces method overloading, but there is a difference here, method overloading is a static variant of ad hoc polymorphism whereas union types and subclassing are runtime variants of it, they should be orthogonal.
You could also argue that typeclasses replace method overloading, but we need typeclasses anyway.

@160R wrote:

Generate wrapper class with constructors for all possible values?

Then you implement union types over and over again from. Furthermore, you will need compiler support such that methods accepting all types accepted by your Json type accepting also the Json type itself and implicit extract the json inner value into a value of its accepting types.

@damianw wrote:

The last of these overloads is for “throw your hands in the air and hope you have one of those types”. We could do better if we had polymorphic dispatch, which is related to (and can be solved by?) union types.

You don’t need polymorphic dispatch for this scenario, rather it would be better to provide only one signature of type union.

@SkittishSloth wrote:

I was thinking this could be why; if you have a union type that would generate overloads, you might run into a conflict with a separate, manual overload.

Good point, what we need are either overload conventions for ambiguities or we don’t compile.