does anyone know if `b in a..c` has the same perfo...

# getting-started

[cheeze2000]

does anyone know if b in a..c has the same performance as a <= b && b <= c ?

[Starr]

I think it gets optimized into the same bytecode

[cheeze2000]

thank you

[cheeze2000]

i would believe so

[ephemient]

yes, https://github.com/JetBrains/kotlin/blob/master/compiler/backend/src/org/jetbrains/kotlin/codegen/range/inExpression/InIntegralContinuousRangeExpressionGenerator.kt

[ephemient]

there's a test to ensure that these do not produce any function calls https://github.com/JetBrains/kotlin/blob/master/compiler/testData/codegen/bytecodeText/ranges/inNonMatchingRangeIntrinsified.kt

[cheeze2000]

oh i see, i would assume it also works for Chars right? '0'..'9'

[cheeze2000]

i would use the Char.isDigit() method but apparently it includes other numeric characters from different languages

[ephemient]

https://github.com/JetBrains/kotlin/blob/master/compiler/frontend/src/org/jetbrains/kotlin/types/RangeUtil.kt#L47 yes, char is included in what gets intrinsified

[ephemient]

also any Comparable in a different optimization, which of course just eliminates the range, as it still needs the compare() function call

[cheeze2000]

thanks a lot 👍

[Klitos Kyriacou]

Now that one was easy to optimize. How about c in ('a'..'z') + ('A'..'Z') + ('0'..'9') ?

[ephemient]

no, that results in a List<Char> and .contains

[cheeze2000]

oh i see. so it's better if you do c in 'a'..'z' || c in 'A'..'Z' i suppose?

[Starr]

I'm honestly not sure, and I think this starts to get into preoptimization territory -- for 99% of applications it doesn't matter.
In any case, I think you could use Char.isLetter() (and pass in a Locale if that really matters to you).

[Klitos Kyriacou]

How do we pass in a Locale?

[Starr]

isLetter has an optional Locale parameter, just pass it in

[Klitos Kyriacou]

It doesn't seem to be documented: https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.text/is-letter.html

[Starr]

Maybe it's in Java's Character? idk

[ribesg]

If such optimization really matters I would at least encapsulate it in an inline extension