:thinking_face:

# announcements

[Fleshgrinder]

🤔

[Fleshgrinder]

it is a ByteArray

[Fleshgrinder]

This fixes it but the reason why I have to call the conversion only for that particular number is beyond me.

[spand]

Bytes are signed

[Fleshgrinder]

I see, still, seems rather arbitrary.

[spand]

ie. 0x80 is 128 which cannot fit into a signed byte which has a max value of 127.

[Fleshgrinder]

I understood but it's still rather arbitrary why one has to manually transfrom those but not the others. It is in general a pain to work on such a low level with Kotlin I'm afraid.

[marstran]

Hmm, it's not really arbitrary that the number is out of range?
Kotlin is pretty consistent in that it doesn't perform any implicit conversions between the number-types.

[Fleshgrinder]

The inconsistency that I see is that 0x80 is reported as integer literal whereas 0x00 is considered a byte literal. How come? Why is 0x00 not considered an integer literal?

[Fleshgrinder]

The inconsistency continues with 0.toByte(), 0.toShort(), 0, and 0L. 😛

[diesieben07]

0x00 can be both an integer or byte (or short) literal.
0x80 can only be an integer because it's not a valid byte.

[diesieben07]

val x: Int = 0x00 // valid
val y: Byte = 0x00 // valid
val z: Int = 0x80 // valid
val w: Byte = 0x80 // invalid, not a byte.

[Fleshgrinder]

So it does implicit conversion. 😉

[Fleshgrinder]

That's my whole point here.

[diesieben07]

No, it does not convert.

[diesieben07]

0x00 has different types, depending on context.

[diesieben07]

Once it's inferred to be an Int, it stays an int, unless you explicitly convert.

[Fleshgrinder]

Which means its type is converted based on context.

[diesieben07]

It is not converted.

[diesieben07]

Conversion implies it is first one type and then another.

[diesieben07]

val x: Byte = 0x00 does not do any conversion. It simply "creates" a byte.

[Fleshgrinder]

Technically correct yes, it still seems arbitrary and I would clearly prefer it to be more consistent and strict with this.

[diesieben07]

Again, what's arbitrary?

[gian]

It’s the same as other types:

val b: Int = 1
val a: Long = 1

[Fleshgrinder]

Prints 0

Untitled

[Fleshgrinder]

Rust: error[E0277]: cannot subtract i64 from i32

Untitled

[gian]

That’s because there is a operator fun minus defined for Int that accepts Long

[diesieben07]

- is overloaded in Kotlin to allow Int.minus(Long). It returns a Long.
It's perfectly reasonable, imho.

[diesieben07]

You can even click on the - to jump to the definition.

[Fleshgrinder]

That is reasonable, yes. I'm still disappointed. Here the type is correctly inferred by Rust and that's what I would expect from Kotlin.

Untitled

[diesieben07]

I am not familiar with Rust, but I'd assume that those are unsigned bytes?

[Kroppeb]

u8 seems unsigned

[Fleshgrinder]

u8 is unsigned but 0x80 does not carry that info.

[Kroppeb]

no 0x80 is inferred to be an u8 out of context

[diesieben07]

buf[6] is unsigned. buf[6] & 0x0f is therefor also unsigned.

[Fleshgrinder]

In Kotlin (see screenshot above) I have to place the u after each literal.

[diesieben07]

Now we are getting somethere. That is a valid bug report.

[Kroppeb]

Cause unsigned types are experimental

[Fleshgrinder]

But I have opted in, that's not a real excuse imho.

[Kroppeb]

I think they want the explicit opt-in atm

[Fleshgrinder]

@ExperimentalUnsignedTypes how much more explicit?

[Fleshgrinder]

There are already a couple of reports regarding this topic:
- https://youtrack.jetbrains.com/issue/KT-4749
- https://youtrack.jetbrains.com/issue/KT-25996
- https://youtrack.jetbrains.com/issue/KT-26835

[theyann]

@Fleshgrinder just out of curiosity, why do you need to be so low level ? Just wondering but I never need to handle byte shifting so I'm wondering in what kind of context you'd need this.

[Fleshgrinder]

#CKTMRFQ2Z see also https://youtrack.jetbrains.com/issue/KT-31880

[Fleshgrinder]

The code above is for UUIDv5 (SHA-1) and I'm setting the version to 5 (first line) and the variant to RFC 4122 (second line).

[theyann]

ok thanks

[Fleshgrinder]

🙂

[dfriehs]

This is because hex literals in kotlin are always signed (which in my opinion is horrible), the byte literal for 0x80 is -0x80

[Fleshgrinder]

🤝

[Fleshgrinder]

😞

[Kroppeb]

I think that's also an issue with normal ints and bytes

[gildor]

Hex literals are always signed because there are no unsigned types in Kotlin before 1.3 (and even now they are experimental), same as in Java (and JS)