Norbi04/16/2023, 1:05 PM
is expected (in my case it was a generic function with a type parameter
). 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 from
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
and not an
? It has only some abstract functions, nothing else. Thanks.
ephemient04/16/2023, 1:11 PM
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
Norbi04/16/2023, 1:14 PM
you can't do arithmetic onIt's true, the function I mentioned calls onlyanyway, it's almost never useful, so IMO it's fine
. 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.
elect04/18/2023, 5:19 AM
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