<@U33H6SB2B> I'm not sure if having `Uint8Array.ge...

# javascript

[Edoardo Luppi]

@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.

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.

[turansky]

It's safest option, which we have for now

[Edoardo Luppi]

But it's conceptually wrong tho

[turansky]

Byte was previously and it doesn't work as required

[Edoardo Luppi]

What do you mean with it does not work? It's a signed type, but it can easily be treated as unsigned.

[turansky]

No :)

[turansky]

Details you can find in Wrappers issues

[Edoardo Luppi]

Why not? But again, Short's behavior in Kotlin reflects what short means on the JVM, which is not what we want.

[Edoardo Luppi]

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().

[turansky]

Both variants are bad

[turansky]

Short is less bad 😉

[Edoardo Luppi]

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

[turansky]

Option, which we discuss - use UByte with compiler plugin support

[turansky]

If you are ready to help - please ping me in DM

[Edoardo Luppi]

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.

[turansky]

Uint8Array has the same “problem”

[Edoardo Luppi]

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.

[turansky]

With Short it works as required

[turansky]

Example

[turansky]

For now I see only reasons to use Short

[Edoardo Luppi]

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

[turansky]

You are unsafe in both cases

[turansky]

Probably you should use UByte in common code and safe convertion to Short on final stage