Why is `Number` not operable in the JVM? Why did S...
# announcements
h
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?
s
What does
4 + NaN
equal?
h
4
s
Why?
And is it 4 or is it 4.0?
’cause the two data types are disparate
h
that or
error("You cannot add NaN to a number")
it's 4 if it's not rational
s
but you can’t have your return type vary like that, right?
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
h
basically what I'm recommending is simply that the
Number
class has the following added:
Copy code
abstract operator fun <N: Number> plus(other: N): N

// etc for others
then all the inheritors simply override that, instead of all individually implementing them
so if you add another type to your number, you must return that type
s
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
h
or that
Number
become
Copy code
abstract class Number<N: Number<N>>()
and therefore you can only do the operations on a number of the same type
BUT
at least you could then make general number functions
i understand that you're just picking my brain, and getting me to consider all the cases, and I appreciate that.
s
what’s the point. though? this just obscures nuance between data types and creates room for subtle bugs and pseudo-nondeterministic behavior
h
so why do essentially all other languages outside of jvm ones not have this problem?
s
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)?
bonus - what languages do so without ever losing precision or making overflow behavior ambiguous?
h
I'm not actually asking for the compiler to try to optimize the number type
s
Who said anything about compiler optimizations?
h
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
so you can make generic functions like
fun adder<N: Number>(a: N, b: N): N = a + b
if you put doubles in there, you get a double, etc
s
I mean, you won’t know it’s a double really, it’d just be
Number
which means that 2+2 can no longer trivially be
(int) 4
h
i see
s
there’s a lot of wacky stuff that could go on under the hood that really would not be obvious
what if some operations eventually coerced a
float
up to a
BigDecimal
?
if it’s all just
Number
throughout, that seems like a nightmare to debug
well, perhaps not debug in that case, maybe just profile in terms of performance
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)
also by being like “lol types”
In a strict sense… I think you could implement that generic
adder()
function as is - just with a lot of runtime typechecking
Copy code
return when (lhs) {
  is Double -> when (rhs) {
    is Double -> lhs + rhs  // return a Double, but it's a Number™