https://kotlinlang.org logo
Join Slack
Powered by
Why is JB reluctant to add sum/union types? e.g. `...
# announcements
h
Why is JB reluctant to add sum/union types? e.g.
Copy code
fun <N: Int | Byte> foo(n : N) = n.toDouble() / 4.5
TypeScript has them, so I'd imagine JB would want to have it for Kotlin/JS.
n
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
h
okay, fine, i'll rewrite it
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
Copy code
operator fun BigInteger.plus(other: Int) = ...

fun <N: Int | BigInteger> foo(n: N) = n + 5
right now the only way to accomplish a restriction of which 
Number
subclasses you allow is to duplicate the function over and over
n
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?
m
Do you have a KEEP link or something about this proposed feature?
h
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
t
Actually, 
BigInteger
is a subclass of 
Number
. As is 
BigDecimal
.
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.
h
Oh, sorry, yeah
I updated the post. Oopsie! I so rarely use js instead of ts
@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
t
If you use 
Navigate->Type Hierarchy
on kotlin's 
Number
in IntelliJ, it shows you 
java.lang.Number
, suggesting it's a typealias.
n
imho, this destroys the liskov substitution principle and is an open door to a lot of problems
t
In what way?
h
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
n
@Toddobryan please refer to my example above about 
n.ushr(1)
t
If 
ushr()
isn't defined in 
Number
, then there's no problem.
n
it’s defined in 
Int
, but not in 
BigNumber
so, how can you call it on 
n
?
h
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
n
then why isn’t just using 
Number
enough?
t
It is in this case, but there are cases where union types are really useful.
h
What if you want to exclude some subclasses of Number?
t
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.
@Hullaballoonatic Just for fun, try
Copy code
import java.lang.BigInteger

fun main(args: Array<String>) {
    println(BigInteger("123") is Number)
}
That should be using 
kotlin.Number
and I get a highlight in IntelliJ saying "Check for instance is always true".
I can't explain why that is, based on the Kotlin code, but something weird is happening.
h
yeah, i'm confused
m
Union types could work well with smart casting. For example:
Copy code
fun functionThatCanFail() : String | Failure {
    // ...
}

when(val res = functionThatCanFail()) {
    is Failure -> // Handle the error
    is String -> // Do something with the result
}
➕ 3
t
That is much clearer than the 
fold(onSuccess, onFailure)
pattern that we keep finding ourselves using.
👍 1
k
I think Kotlin Number is just mapped to Java Number like so many other magic mappings like List and Set etc.
j
union types are fantastic 👍
m
@jw You only write that because of https://twitter.com/JakeWharton/status/1188840311063302144 😁
👌 1
s
r
3 Views
Open in Slack
PreviousNext
Powered by