https://kotlinlang.org logo
Title
n

Norbi

04/16/2023, 1:05 PM
I started to use unsigned integers and I was surprised that I cannot use them where a
Number
is expected (in my case it was a generic function with a type parameter
<T: Number>
). I have checked the corresponding KEEP and found this:
Number
is an abstract class in Kotlin, and inline classes are not allowed to extend other classes, therefore unsigned types can't be inherited from
Number
class.
We haven't found compelling use cases to circumvent this limitation specially for the unsigned types.
My questions: 1. Is it really "good enough" to have non-unified "number" handling in Kotlin? 2. Why is
Number
an
abstract class
and not an
interface
? It has only some abstract functions, nothing else. Thanks.
e

ephemient

04/16/2023, 1:11 PM
1. you can't do arithmetic on
Number
anyway, it's almost never useful, so IMO it's fine. 2. that's how it is in Java, and Kotlin can't change the shape of the existing class hierarchy
n

Norbi

04/16/2023, 1:14 PM
you can't do arithmetic on
Number
anyway, it's almost never useful, so IMO it's fine
It's true, the function I mentioned calls only
toInt()
on the
<T: Number>
. Not a big deal, I create an overloaded variant of the function, I was just curious.
that's how it is in Java
I knew it that it was because of Java compatibility! 🙂 Thanks.
e

elect

04/18/2023, 5:19 AM
I disagree, doing arithmetic on
Number
is useful when you have to perform the same operations on generic number inputs (eg: slider in UI). Right now I'm forced to duplicate some code because of that. That's exactly the biggest reason I'm locked on keep using unsigned