Norbi
04/16/2023, 1:05 PMNumber
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:
is an abstract class in Kotlin, and inline classes are not allowed to extend other classes, therefore unsigned types can't be inherited fromNumber
class.Number
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.ephemient
04/16/2023, 1:11 PMNumber
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 hierarchyNorbi
04/16/2023, 1:14 PMyou can't do arithmetic onIt's true, the function I mentioned calls onlyanyway, it's almost never useful, so IMO it's fineNumber
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 JavaI knew it that it was because of Java compatibility! 🙂 Thanks.
elect
04/18/2023, 5:19 AMNumber
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