Locale-agnostic case conversions by default

[qurbonzoda]

This issue is to discuss the proposal to introduce case conversion API that do not depend on the default locale settings in standard library.

The new API includes:

• String.uppercase(): String
• String.lowercase(): String
• Char.lowercase(): String, Char.lowercaseChar(): Char
• Char.uppercase(): String, Char.uppercaseChar(): Char
• Char.titlecase(): String, Char.titlecaseChar(): Char
• String.replaceFirstChar(transform: (Char) -> Char): String
• String.replaceFirstChar(transform: (Char) -> CharSequence): String

They are to replace existing locale-sensitive API.

The proposal text is here.

[edrd-f]

What about uppercaseFirst and lowercaseFirst instead of capitalizeFirst and decapitalizeFirst? Looks more intuitive since capitalization is related to the whole string, so (de)capitalizeFirst sounds strange.

[OliverO2]

The proposal makes sense to me. I agree that (de)capitalizeFirst sounds strange as it expresses the same effect twice.

Additionally, such functions typically name their result (not the process), so I'd suggest these replacements:

• String.capitalized() and String.capitalized(locale: Locale)
• String.decapitalized() and String.decapitalized(locale: Locale)

[edrd-f]

Problem is that it's only one letter from the original (de)capitalize() functions, making it easy to use the wrong one, especially with IDE autocomplete.

[OliverO2]

True, that where I'd hope that the Kotlin IDE plugin will always point to the right version and steer users away from the deprecated one.

[Miha-x64]

String.func(): String

Such an approach involves calling existingCharSequence.toString().func() and creating two copies.
It looks more thrifty to implement CharSequence which will proxy to original sequence calling toUpperCase/toTitleCase/toLowerCase for characters which require this, and one could call toString explicitly to evaluate into a 'normal' String eagerly, if this is required.

Caveats:

• if a (de)capitalized code point occupies different number of UTF-16 words, well, this is a disaster;
• Android has its own GetChars interface which would be nice to implement.

---

What about uppercaseFirst

@edrd-f, first character should be transformed to title case, not to upper case.

[fluidsonic]

I'd also prefer to avoid ed endings like in uppercased.
Most Kotlin API doesn't use it. E.g. it's map and filter, not mapped and filtered.

In the past capitalize was quite confusing. I've always assumed that it affects the entire string.
So the First suffix is welcome here.

Until @Miha-x64's comment I didn't even know that titlecase is a thing in Unicode and differs from uppercase.
Since unicode.org calls it titlecase, why not have it consistent and use titlecaseFirst?

As for the opposite, I wonder whether this is actually useful.
Titlecasing or uppercasing the first character isn't always reversible because there's information loss.

"ß".capitalize().decapitalize() // sS
"ß".uppercaseFirst().lowercaseFirst() // sS // hypothetical

Oops.

I'd deprecate and then remove decapitalize without replacement.

[Fleshgrinder]

Why would capitalize transform the first to title case and not simply uppercase? Is this part of the capitalize meaning in Unicode? If so, or if its meaning is not clear, then we should shy away from introducing them. I mean, the whole reasoning behind this KEEP is around APIs that are hard to use because what they actually do is only explained in their comment.

I think that the following...

fun String.uppercase(): String
fun String.uppercaseFirst(): String
fun String.lowercase()
fun String.lowercaseFirst(): String

...creates a nice API that has symmetry and autocompletes perfectly. Sure, some Unicode characters won't go in both directions but that's a Unicode problem and not ours to solve. (There is a capital ẞ, hence, they are sometimes solving these issues.)

Also, a function that transforms only the first char to title case should be called titlecaseFirst and not capitalize for the same reasons and least surprise.

I really like the proposal and fully support it. It's cumbersome to explain this in every PR.

[fluidsonic]

What's the use case for uppercase/lowercaseFirst?

[janvladimirmostert]

snake_case.split("_").map { it.capitalize() }.joinToString("") // outputs camelcase

…

On 2020/10/11 21:59, Marc Knaup wrote: What's the use case for |uppercase/lowercaseFirst|? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#223 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AARLC5UG66A5YP6KUQJK5E3SKIFALANCNFSM4SECADTQ>.

[fluidsonic]

FYI capitalize as it is implemented today uses titlecase. Uppercase only as a fallback.

[janvladimirmostert]

Capitalize is quite useful when doing code translation and translating someone's variable names from snake case (Python to Kotlin translation or in one case, i parsed somebody's ANTLR file and generated a cleaner ANTLR file stripping all snake_case.
I've not used it for anything else though, but have not had issues with it either (maybe since everything was 100% English)

Not sure what one would use decapitalizeFirst for, unless it's more efficient than just lowercasing the whole String?

Looks interesting

[Fleshgrinder]

UpperCamelCase becomes lowerCamelCase with lowercaseFirst so it clearly provides the same value. Same for lowerCamelCase to UpperCamelCase, but only if it's uppercase and not title case.

[qurbonzoda]

There is a lot of confusion around titlecase vs uppercase. As @fluidsonic has already mentioned, here is what Unicode says:

Titlecase takes its name from the case format used when forming a title, in which the initial letter in a 
word is capitalized and the rest are not. Titlecase is also used in forming a sentence by capitalizing 
the first word, and for forming proper names. The titlecase mapping in the Unicode Standard is the mapping 
applied to the initial character in a word.

The titlecase mapping in Unicode differs from the uppercase mapping in that a number of characters 
require special handling. These are chiefly ligatures and digraphs such as 'fl', 'dz', and 'lj', plus a number
of polytonic Greek characters. For example, U+01C7 (LJ) maps to U+01C8 (Lj) rather than to U+01C9 (lj).