There are other cases, where you must use toByte()...

# language-proposals

[gildor]

There are other cases, where you must use toByte():
byteArrayOf(0xB0.toByte(), 0x7B.toByte(), 0x00.toByte())

[ianbrandt]

I'm not sure I follow your meaning, @gildor. Are you commenting in favor of or against byte literals, or just adding an FYI?

byteArrayOf(0xB0.toByte(), 0x7B, 0x00) works. The only reason you need the toByte() on 0xB0 is because it's not a valid signed two's complement byte, and needs to be truncated.

In either case, byte literals are not needed here as the type is inferred from the parameter type: `byteArrayOf(vararg elements: Byte)`: byteArrayOf(11, 123, 0). As a consequence of this proposal, I would assume they could be used though, if desired: byteArrayOf(11b, 123b, 0b) (or (11y, 123y, 0y)).

[gildor]

Yes, you right

[benleggiero]

This is just ugly, IMO. The language literal and implementation bit-length should be separated.

[benleggiero]

also @ianbrandt, would 0xB0 require .toByte() in Kotlin/Native? I’ve not read up too much bit I think there are `UInt8`s over there which would gladly hold a 0xB0

[ianbrandt]

@benleggiero, What specifically are you saying is ugly, my proposed byte and short literals, hex literals with toByte() calls, or something else?

Also, how does hex literal assignment to unsigned types apply to the addition of byte and short literals to Kotlin? Presumably, the compiler should accept any literal for assignment if it represents a valid value for a known type (after any implicit conversion, which Kotlin eschews: https://kotlinlang.org/docs/reference/basic-types.html#explicit-conversions), and reject it otherwise.

[gildor]

favor of or against byte literals, or just adding an FYI?

In favor. but my example obviously wrong