`String.getOrNul(index: Int): Char` where `nul` is...

# stdlib

[elect]

String.getOrNul(index: Int): Char where nul is \u0000

[edrd]

Just use getOrNull(index) ?: "\u0000"?
Makes it much clearer what is going on. No need for a function on the stdlib.

[elect]

simply more verbose

[edrd]

Then write your own extension function

[elect]

sure, but it'd be better to have it in the stdlib

[edrd]

Standard library is for code that is commonly needed by many people

[elect]

everyone else working with native strings

[edrd]

Which is 0.0001% of developers

[elect]

just let me suggest you the existance of kotlin-native

[gildor]

too narrow use case for stdlib imo
Especially getting into account a lot of possible confusion between getOrNull and getOrNul

[gildor]

and if you rename to getOrNullTerminator or something like this, a bit more obvious, it becomes not much shorter

[miha-x64]

UTF-16 Char and most of functions accepting or returning it are useless and should be deprecated.

[elect]

confusion may be still be minimized by the fact they get listed consecutively when a suggestion is requested (alignment makes it easy to spot the difs)

[elect]

@miha-x64 in favour of? utf32? utf8?

[diesieben07]

in favor of unicode codepoints, represented as Int (an inline class for those would be nice in the stdlib though maybe).

[elect]

this has to come from oracle first though, you know

[diesieben07]

java.lang.String already provides an API to deal with code points.

[elect]

however @diesieben07 representing unicode using an Int essentially means utf32

[elect]

which can be quite expensive for most of the simple scenarios

[elect]

(even in comparison to utf8, utf16 can be expensive, this is the very reason they introduced utf8 strings in Java under the hood now)

[diesieben07]

I am not saying to store strings as an IntArray, which would be utf32. What I am saying is that when working with a String object you shouldn't have to deal with the intricacies of the underlying storage format.

[elect]

ah, got it

[diesieben07]

So for example someString.length should be the number of code points, not the number of utf 16 chars. its the same issue you have in languages that represent strings as byte arrays, where you now have to deal with the byte lenght of a string in utf-8 instead of its actual length.

[Marc Knaup]

The Swift team has put a lot of effort into working out a solid String API. It operates on code points. It offers UTF-8 and UTF-16 access through “views” on a String.

https://docs.swift.org/swift-book/LanguageGuide/StringsAndCharacters.html#ID301