Why is JB reluctant to add sum union types e g ```fun lt N I

Question

Why is JB reluctant to add sum union types e g ```fun lt N Int | Byte gt foo n N = n toDouble 4 5``` TypeScript has them so I d imagine JB would want to have it for Kotlin JS

nfrankel · Answer

i don t understand your comment javascript is not a statically typed language in a statically typed language `Int` and `Long` inherit from `Number` and thus have the same functions available but `BigInteger` doesn t so it doesn t make any sense

Hullaballoonatic · Answer

okay fine i ll rewrite it

Hullaballoonatic · Answer

there ya go it s more about restricting members of a shared inheritance than about creating some kind of amalgam type but it would also be nice to be able to do something like ``` operator fun BigInteger plus other Int = fun lt N Int | BigInteger gt foo n N = n + 5```

Hullaballoonatic · Answer

right now the only way to accomplish a restriction of which `Number` subclasses you allow is to duplicate the function over and over

nfrankel · Answer

again if you allow sum types that means you can call any function of `Int` or `BigInteger` on `n` e g `n ushr 1 ` cf <https kotlinlang org api latest jvm stdlib kotlin int ushr html> this is valid for `Int` but not for `BigInteger` do you see the issue

Mark Murphy · Answer

Do you have a KEEP link or something about this proposed feature

Hullaballoonatic · Answer

yes i presume that issued would be resolved you would have a compiler error saying that the function you are trying to call does not exist on all types in your sum type

Toddobryan · Answer

Actually `BigInteger` is a subclass of `Number` As is `BigDecimal`

Toddobryan · Answer

I think < Hullaballoonatic> was talking about TypeScript which does have union types For this example though `Byte` `Short` `Int` `Long` `Float` `Double` `BigInteger` and `BigDecimal` as well as `AtomicInteger` `AtomicLong` and `Striped64` if those are at all helpful are all subtypes of `Number` There does seem to be some weirdness with type inference though which may have to do with the interplay of typealiases and the Java types I don t know I m having to add an `as Number` where it shouldn t be necessary to get things to compile

Hullaballoonatic · Answer

Oh sorry yeah

Hullaballoonatic · Answer

I updated the post Oopsie I so rarely use js instead of ts

Hullaballoonatic · Answer

< Toddobryan> I believe it s because `Byte` `Short` `Int` `Char` `Long` `Float` `Double` all inherit from Kotlin s `Number` not Java s `BigInteger` etc being java libraries would not inherit from Kotlin s number

Toddobryan · Answer

If you use `Navigate gt Type Hierarchy` on kotlin s `Number` in IntelliJ it shows you `java lang Number` suggesting it s a typealias

nfrankel · Answer

imho this destroys the liskov substitution principle and is an open door to a lot of problems

Toddobryan · Answer

In what way

Hullaballoonatic · Answer

Kotlin s number is just an abstract class containing only abstract methods to convert to other basic numbers It does not inherit from Java s number

nfrankel · Answer

< Toddobryan> please refer to my example above about `n ushr 1 `

Toddobryan · Answer

If `ushr ` isn t defined in `Number` then there s no problem

nfrankel · Answer

it s defined in `Int` but not in `BigNumber` so how can you call it on `n`

Hullaballoonatic · Answer

This is the entirety of `Number` <https kotlinlang org api latest jvm stdlib kotlin number index html> so the code in my OP would not compile if you tried to call a function that isn t in `Number`

nfrankel · Answer

then why isn t just using `Number` enough

Toddobryan · Answer

It is in this case but there are cases where union types are really useful

Hullaballoonatic · Answer

What if you want to exclude some subclasses of Number

Toddobryan · Answer

Especially in TypeScript since it was normal JavaScript style to have parameters or returns that were things like `array` or `string` You need union types to handle those cases in a type safe way

Toddobryan · Answer

< Hullaballoonatic> Just for fun try ``` import java lang BigInteger fun main args Array lt String gt println BigInteger 123 is Number ```

Toddobryan · Answer

That should be using `kotlin Number` and I get a highlight in IntelliJ saying Check for instance is always true

Toddobryan · Answer

I can t explain why that is based on the Kotlin code but something weird is happening

Hullaballoonatic · Answer

Hullaballoonatic · Answer

yeah i m confused

marstran · Answer

Union types could work well with smart casting For example ``` fun functionThatCanFail String | Failure when val res = functionThatCanFail is Failure gt Handle the error is String gt Do something with the result ```

Toddobryan · Answer

That is much clearer than the `fold onSuccess onFailure ` pattern that we keep finding ourselves using

karelpeeters · Answer

I think Kotlin Number is just mapped to Java Number like so many other magic mappings like List and Set etc

jw · Answer

union types are fantastic +1

Mark Murphy · Answer

< jw> You only write that because of grin

streetsofboston · Answer

raulraja · Answer