Why is `Number` not operable in the JVM? Why did Sun design it that way and why does JB not fix it i...

# announcements

[Hullaballoonatic]

Why is Number not operable in the JVM? Why did Sun design it that way and why does JB not fix it in Kotlin? Everything (afaik) that inherits from Number is operable, so why wouldn't the operators be refactored to be included there?

[Shawn]

What does 4 + NaN equal?

[Hullaballoonatic]

4

[Shawn]

Why?

[Shawn]

And is it 4 or is it 4.0?

[Shawn]

’cause the two data types are disparate

[Hullaballoonatic]

that or error("You cannot add NaN to a number")

[Hullaballoonatic]

it's 4 if it's not rational

[Shawn]

but you can’t have your return type vary like that, right?

[Shawn]

4.0, NaN, and 6.9 are all valid float values - you can’t vary the return type of a function based on the value of its arguments

[Hullaballoonatic]

basically what I'm recommending is simply that the Number class has the following added:

abstract operator fun <N: Number> plus(other: N): N

// etc for others

[Hullaballoonatic]

then all the inheritors simply override that, instead of all individually implementing them

[Hullaballoonatic]

so if you add another type to your number, you must return that type

[Shawn]

but to what end? adding them to the Number API means that you can reasonably perform those operations with two of any given number, which is decidedly not the case

[Hullaballoonatic]

or that Number become

abstract class Number<N: Number<N>>()

and therefore you can only do the operations on a number of the same type

[Hullaballoonatic]

BUT

[Hullaballoonatic]

at least you could then make general number functions

[Hullaballoonatic]

i understand that you're just picking my brain, and getting me to consider all the cases, and I appreciate that.

[Shawn]

what’s the point. though? this just obscures nuance between data types and creates room for subtle bugs and pseudo-nondeterministic behavior

[Hullaballoonatic]

so why do essentially all other languages outside of jvm ones not have this problem?

[Shawn]

I mean, I’m not much of a polyglot all things considered - what statically typed languages have a parent Number class its numeric datatypes all inherit from and can all be arbitrarily added (due to its supertype guaranteeing mathematical operations)?

[Shawn]

bonus - what languages do so without ever losing precision or making overflow behavior ambiguous?

[Hullaballoonatic]

I'm not actually asking for the compiler to try to optimize the number type

[Shawn]

Who said anything about compiler optimizations?

[Hullaballoonatic]

i'm only asking that the operations that they all share, that work exclusively with their own class, be refactored up into number, so that you always know that if you have an object of type number, whatever class it is an instance of, it has +,-,/,*,%,etc

[Hullaballoonatic]

so you can make generic functions like fun adder<N: Number>(a: N, b: N): N = a + b

[Hullaballoonatic]

if you put doubles in there, you get a double, etc

[Shawn]

I mean, you won’t know it’s a double really, it’d just be Number

[Shawn]

which means that 2+2 can no longer trivially be (int) 4

[Hullaballoonatic]

i see

[Shawn]

there’s a lot of wacky stuff that could go on under the hood that really would not be obvious

[Shawn]

what if some operations eventually coerced a float up to a BigDecimal?

[Shawn]

if it’s all just Number throughout, that seems like a nightmare to debug

[Shawn]

well, perhaps not debug in that case, maybe just profile in terms of performance

[Shawn]

JavaScript “gets around” this by literally giving you nothing but IEEE 754 floating point (i.e. no integers or any other numeric data type unless you create them yourself)

[Shawn]

also by being like “lol types”

[Shawn]

In a strict sense… I think you could implement that generic adder() function as is - just with a lot of runtime typechecking

[Shawn]

return when (lhs) {
  is Double -> when (rhs) {
    is Double -> lhs + rhs  // return a Double, but it's a Number™