Maanrifa Bacar Ali
11/22/2025, 11:44 AMString.utf8size() has internal visibility instead of public? Because it is used here as an example but that example cannot be reproduced in external projects. The equivalent function in Okio was public. Other examples in the kotlinx-io documentation use String.encodeToByteArray(), so I'm not sure if it is the approach to go with when using kotlinx-io compared to Okio regarding UTF-8 strings.Filipp Zhinkin
11/24/2025, 3:09 PMinternal intentionally, and its use in the sample is an oversight, thanks for pointing to it!
There's a proposal to make the function public and the discussion on why it may not be as trivial as it seems: https://github.com/Kotlin/kotlinx-io/issues/258Maanrifa Bacar Ali
11/25/2025, 10:18 PMencodeToByteArray isn't returning the same value independently of the platform. I was wrongly assuming that stdlib's APIs produces the same result on all platforms while they might compute differently.
Now that I'm aware of that, for my particular case I can't rely on encodeToByteArray as the encoded data I'm producing need to be decoded by any device regardless of the platform and the decoded data must be the same as the original non-encoded data.
Now that you know my position, I'll be the first to opt-in to the DelicateIoApi if the API is made public as long as it never changes (more especially in the case kotlinx-io 's behaviour is aligned with that of the stdlib in the near future) 😁. I prefer not to depend on the okio integration just for that particular utf8Size and related writeUtf8. Also I prefer not to copy the String related code from kotlinx-io to ensure the same encoding/decoding behaviour.
Furthermore, I'm among those who believe that differences in the behaviour of encodeToByteArray (and other functions) across platforms are undesirable and that the standard library should be consistent. That said, I know it's not that simple ☝🏽