What in the world was the justification for this?

# announcements

[serebit]

What in the world was the justification for this?

[Casey Brooks]

That is disgusting. Capitalize is such a useful function, it drives me crazy that more languages don’t support it. Please don’t remove this from Kotlin!

[nanodeath]

is that in 1.5?

[nanodeath]

capitalize does seem kinda niche...

[randomcat]

It's deprecated because it's locale-sensitive

[serebit]

Then why wasn't it replaced with a locale-insensitive API like toUpperCase and toLowerCase?

[nanodeath]

couldn't you say capitalize(Locale) then?

[Casey Brooks]

If you’re doing anything where you put text on a screen (Android, Compose Desktop), .capitalize() is quite invaluable. It seems very strange to remove it rather than creating an overload that accepts a Locale

[Robert Jaros]

https://youtrack.jetbrains.com/issue/KT-43023

[serebit]

The YouTrack issue even states that String.capitalize has moderate usage, where String.decapitalize is relatively rare. So why was it removed entirely with the only replacement being a significantly longer function call?

[serebit]

Replace it with a locale-agnostic API like the others!

[randomcat]

It's possible that the issue is naming it

[serebit]

.capitalized(), .decapitalized(). Problem solved.

[nanodeath]

yeah like I'm going to notice that in code reviews 😛

[randomcat]

it's also inconsistent with the other functions being imperative

[serebit]

uppercase is an adjective, capitalize is a verb, capitalized is an adjective.

[serebit]

capitalized is imperative.

[randomcat]

"capitalized" is not imperative, "capitalize" is

[nanodeath]

maybe worth discussing either on the forum or #C0B9K7EP2?

[nanodeath]

the removal timeline is pretty far out (1.7)

[Casey Brooks]

There’s a whole KEEP for it https://github.com/Kotlin/KEEP/blob/master/proposals/stdlib/locale-agnostic-case-conversions.md

[nanodeath]

Status: Under consideration

somewhat out of date 🙂

[serebit]

"we're going to provide a more orthogonal replacement"

[nanodeath]

To overcome the issue we would like to deprecate the current API and introduce new locale-agnostic functions.

this does feel like overstepping to me -- maybe let people make bad decisions

[Casey Brooks]

Maybe I just don’t understand the issue, but wouldn’t a completely locale-agnostic API still likely be incorrect? Like, how do those functions actually do conversions without a locale? Just using ASCII characters (i.e. only support English)?

[randomcat]

using the root locale

[nanodeath]

the invariant locale in other Kotlin platforms.

I'm similarly confused by this. this just means other platforms don't support locales?

[Casey Brooks]

It seems like the problem is when you use those conversion functions assuming a default locale. Making them locale agnostic is still assuming a locale (the root locale), and that assumption might still be wrong from the user’s perspective


I’d think a better solution would be to introduce some sort of Locale abstraction that each respective platform can work with for these kinds of functions, and make the new functions require that locale.

[nanodeath]

it's a bummer String itself doesn't store the locale

[Casey Brooks]

To obtain correct results for locale insensitive strings, use toUpperCase(Locale.ROOT).

making the API locale agnostic isn’t going to remind users that those functions should only be used on locale-agnostic text. It’s just going to be abused in the same way as the current functions

[nanodeath]

@randomcat what 😛

[randomcat]

ignoring the locale when you should have used it is better than using the locale when you should have ignored it

[randomcat]

String is a set of code points, it has no business storing a locale

[nanodeath]

it's a moot point anyway because we can't modify String, Oracle can't modify String, and we're not going to create a String alternative class

[Justin Tullgren]

If its that important for an app, just make an extension function? Have that call the agnostic api with an approved default locale...?

[Justin Tullgren]

fun String.toCapitalized(): String = replaceFirstChar { /*default*/ }

[Justin Tullgren]

I agree that String should not store a locale

[nanodeath]

I think the problem is the idea of a "default locale" is flawed

[Justin Tullgren]

agreed, for the standard library. I proposed the extension for app developers if they really want to do that.

[Justin Tullgren]

they can add that to their app extensions. 🤷

[Oliver.O]

Many aspects of the above discussion have already been discussed in https://github.com/Kotlin/KEEP/issues/223, including the naming issues.

[Oliver.O]

The naming discussion (verb or not) has been transferred to https://youtrack.jetbrains.com/issue/KT-43261