https://kotlinlang.org logo
Join Slack
Powered by
<@U33H6SB2B> I'm not sure if having `Uint8Array.ge...
# javascript
e
@turansky I'm not sure if having 
Uint8Array.get/set
use 
Short
as element type is correct in kotlin-wrappers. You end up in situations where you need to return the 
Short
element from a 
Byte
function, which means what you'd naively do is 
get(index).toByte()
, however that changes the representation of the underlying value.
Copy code
toByte(bytes[_unary__edvuaz]) & 255;
I think the appropriate type for 
U*
typed arrays is still 
Byte
, as effectively it's 8 bits, not 16 bits.
t
It's safest option, which we have for now
e
But it's conceptually wrong tho
t
Byte was previously and it doesn't work as required
e
What do you mean with it does not work? It's a signed type, but it can easily be treated as unsigned.
t
No :)
Details you can find in Wrappers issues
e
Why not? But again, Short's behavior in Kotlin reflects what 
short
means on the JVM, which is not what we want.
The clamped array from the GitHub issue is a very niche use case that would probably be better handled as 
0xFF.unsafeCast<Byte>()
. If you try to do the same on a standard 
Uint8Array
, you can simply use 
0xFF.toByte()
.
t
Both variants are bad
Short is less bad 😉
e
Not in a multiplatform context where the concept of byte cannot be mapped to a short. Kotlin performs byte manipulation when transitioning from one number type to another, unlike JS, so this is extremely problematic
t
Option, which we discuss - use UByte with compiler plugin support
If you are ready to help - please ping me in DM
e
It might work, but it feels overly complex for trying to interop with JS in the current setup. I would honestly pick the use case that's definitely more common, and clamped arrays are rare outside of highly optimized environments.
t
Uint8Array
has the same “problem”
e
Not that I know of, see https://pl.kotl.in/ULvFghXfe for the behavior difference. I'm not saying the interop is perfect, but the way the clamped array handles the value you pass in makes it even more problematic.
t
With 
Short
it works as required
For now I see only reasons to use 
Short
e
But how do you handle the case of a multiplatform expect-actual function that returns a 
Byte
? With 
Short
I'm forced to unsafe cast, as converting to a byte will change the number representation
t
You are unsafe in both cases
Probably you should use 
UByte
in common code and safe convertion to 
Short
on final stage
Open in Slack
PreviousNext
Powered by