Make docs of String to number funs a little more clear about digits #5506
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Java
Integer::parseInt
and KotlinString.toInt
and other String to non-float functions accept non-ASCII (aka non-English aka non-Western-Arabic) digits in a String too. For example, Eastern Arabic digits:This is a good and expected behavior in my opinion. I don't know if Kotlin implementation of these functions for non-JVM targets also behave the same way.
Alos, Java
Character::isDigit
and KotlinChar.isDigit
return true for non-ASCII numerals too. Same for"\\p{javaDigit}"
or"\\p{Nd}"
regexes in both Java and Kotlin. See this code snippet. They all match a few hundred types of digit chars in JDK 24.I have updated the docs to hopefully make it just a bit more clear that
0-9
are just one set of chars that are valid as digits. I don't know whether all those functions updated in this commit (especially non-JVM orexpect
ones) accept non-English digits too. If not, then my update for docs of those should be reverted and I hope their implementations is updated to make them behave the same way as on JVM implementation.Another thing is, it seems most of those functions lack unit tests for non-ASCII digits to clarify their behavior. Found a weird bug:
And,
BigDecimal
allows non-ASCII digits in the string, butString.toDouble
and variants throw exception.Related: