Note that currently all those range creation operators will be kinda second-rate in terms of performance on Android: they'll allocate ranges in places where most frequently used stdlib operations don't (compiler magic).

Why is that? Is there a difference between the compiler on Android and on JDK?

No difference on kotlinc side. HotSpot running on a computer powered by city power grid is just so much smarter than Dalvik running on small power-constrained device such as smartphone.

That's for performance-critical code, anyway. Most Android apps are not.

But

..

still compiles down to an index-based for loop, right?

Right. Although if you want to make the most out of it, use

until

;)

(or

indices

. Or a range with const upper bound)

Both HotSpot and Dalvik recognize some particular loop patterns as "countable", those listed above will give you the best performing bytecode.

Difference depends on what exactly you do in the loop, can be as much as 20% for some number crunching.

indices

isn't gonna allocate something?

Not in

in

operator, and not in

for

. Otherwise - yes, all these operations will allocate a range insurance

I find these infos quite valuable, I wish they could be list somewhere

the best source is probably https://youtrack.jetbrains.com/issue/KT-11173

Why doesn’t

when

bind its argument to

it

? It would make

when

so much more useful and readable. I mostly end up with just

when{ ...}

There's a discussion about it here: https://youtrack.jetbrains.com/issue/KT-4895 As Andrey says in a comment; they can't add it now, because it isn't backwards compatible. It would change the meaning of this code:

list.forEach {
    when (foo) {
       1 -> println(it)
    }
}

thanks @marstran

Yup, I wish there was more activity on this library, it's very promising

Q: Is there a stdlib function (or way to combine stdlib functions) to take the first elements of a sequence up to and including an element that meets some predicate?

E.g. something I want something like this (made up) example:

sequenceOf(1,2,3,4,5).takeUntil{it == 3}

which would return

sequenceOf(1,2,3)

there's

takeWhile

, you can do

takeWhile { it != 3 }

That’s not the same. It won’t include the ‘3’ in the returned sequence

This would work

zipWithNext().takeWhile { (prev,next) prev != 3 }.map { it.first }

Except it calculates the next value after the end of the subsequence, which is what I’m trying to avoid

@natpryce I think it doesn't cover a lot of use cases. On the other hand there's a workaround based on

takeWhile

and tracking whether the last item was found with a mutable boolean in a lambda. You could file a feature request though.

@natpryce can there be duplicates in the original list? I.e

{1,3,2,4,3,5

} should return

{1,3}

or

{1,3,2,4,3}

?

Could do something like

numList.minus(numList.takeLastWhile { it != 3 }))

It would stop at the first one.

A more general function would be to split into chunks after “terminator” elements that meet some predicate. Then takeUntil would be split(p).first()

why doesn't

MutableMap.getOrPut

use

V : Any

for the value generic type?

a null value in the map would cause the default value supplier to be called