when reading unicode characters from an StringRead...

# announcements

[Peter Ertl]

when reading unicode characters from an StringReader, should I use method #read() returning [Int] values or is there something else to convert the characters into [kotlin.Char] first ? what is the correct way to represent unicode code points?

[Ruckus]

That's the correct method. The reason it returns int instead of char is so it can return a -1 if you've reached the EOI.

[Peter Ertl]

so basically, after removing -1 Char and Int are equivalent?

[Peter Ertl]

kotlin could probably provider a “nicer” method readChar(): Char? instead I guess

[Peter Ertl]

since using Int for delivering -1 as a sentinel value feels like a quirk

[Ruckus]

This is a Java API, not a Kotlin API. On the JVM all primitives < 32 bits are internally `int`s.

[Peter Ertl]

yeah, I was just thinking of an extension method… thanks for clarifying this, Ruckus 🙂

[Peter Ertl]

I just do it like this now:

[Peter Ertl]

input.read().takeIf { it != -1 }?.toChar()

[Ruckus]

Meh, it's not really any different than any other sentinel value, and has the advantage that it's returning a primitive value, so there's no need for object allocation etc.

[Ruckus]

That will work, but it will box the Int and the Char. Whether that matters is entirely dependent on your use case. In general it's most likely fine, but worth keeping in mind if it's in a hot loop and you see any performance issues.

[Peter Ertl]

I use it to implement a tokenizer used by a parser to evaluate expressions

[Peter Ertl]

thanks a lot for helping 🙂

[Ruckus]

I agree it would be a much cleaner API to use some sort of Option or Result type, but unfortunately those aren't free on the JVM.

[Peter Ertl]

with the introduction of value classes it will probably come sooner or later

[Peter Ertl]

^ which are currently experimental afaik

[Peter Ertl]

‘value class Option<T>’ for the world :-)

[Ruckus]

I doubt it. There's way too much legacy in place to change that, and using -1 as a sentinel is such a well established standard in Java at this point I doubt many will see the need (or want) to change it. I could be wrong though...

[Ruckus]

Even the lowly indexOf uses it.

[Peter Ertl]

true … legacy vs modern api = 1:0 i guess 😛

[Ruckus]

That's my guess, yeah

[ephemient]

even Kotlin's indexOf() uses -1 as a sentinel. that will stay unless there's an inexpensive alternative