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.

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

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.

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