Dear Kotlin community,
Is it possible to have a for-loop in Kotlin with a dynamic step (so it can change)?
I’m having trouble translating the following Java-code into Kotlin:
for(int i = 0; i < 500; i+= (i < 40 ? 10 : 20)) {
System.out.println("Now at "+ i);
}
Is this possible?
I’ve read in an older post (How to for loop with var i) that there is no way to mutate i, so am I right to assume I’ll have to use while?
Thank you.
I think, that you should have never used for loop for that in the first place and it is good that kotlin does not allow this usage. If I understand correctly, in your example variable i is not some kind of index, it has some meaning. And using such variables inside for loop could lead to some nasty side effects in a large code.
Variant using while is not much longer:
var i = 0
while( i < 500 ){
println("Now at $i")
i += if( i < 40 ) 10 else 20
}
Hm, did not see the danger in that, but that’s probably due to my inexperience.
Thanks for the quick answer, much appreciated!
The problem arises when you have a large code.
Pitfall number one: You accidentally or intentionally changing i somewhere inside your loop. You should obviously never do it, but changing the increment is the first step in this direction.
Pitfall number two: For some reason, you want to change the behavior of your dynamic step. You do it in one place, but forget to do in another and now you have two iterations with different number of steps.
Pitfall number three: Suppose you want a more complicated behavior and need three different steps instead of two. You won’t be able to do it with for anymore. You will have to either delegate step calculation to additional function which is even worse, or rewrite everything. In my example you can do it easily by replacing if by when.
Pitfall number four occurs when you have some parallel operations messing with i. In my example, you can simply replace i by AtomicInteger and make your operations thread safe.
There could be additional motivation, but in general I think that classic for loop should be deprecated and replaced by functional-style operations wherever it is possible.
Try to switch your point of view, I hope this code is more readable.
fun main(args: Array<String>){
//sampleStart
(0 until 40 step 10).asIterable()
.plus(40 until 500 step 20)
.forEach { i ->
println("Now at " + i)
}
//sampleEnd
}
Edit: use asSequence instead of asIterable, see below
Hey that looks very intuitive and readable indeed!
Cheers!
The asIterable is not necessary as it is already an Iterable. This can be shortened to the following (and yes the parentheses are necessary):
fun main(args: Array<String>) {
//sampleStart
((0 until 40 step 10) + (40 until 500 step 20))
.forEach { println("Now at $it") }
//sampleEnd
}You are right,
however an Iterable plus another one produces an Iterable,
a Range plus another one produces a List.
Your code allocates the entire array an some -generally- hundreds of Integer (but it is more readable).
@fvasco Iterable concatenated with another Iterable produces List, so again all its elements are materialized.
Did you mean asSequence()?
Ops,
You are right, thanks for reply.
I prefer this solution, I consider this enough readable and has minor memory impact than other implementations.
import kotlin.coroutines.experimental.buildSequence
fun main(args : Array<String>){
//sampleStart
buildSequence {
yieldAll(0 until 40 step 10)
yieldAll(40 until 500 step 20)
}.forEach {
println("Now at $it")
}
//sampleEnd
}
This works if you are experimenting the “coroutinex” library. (False, see below)
This works if you are experimenting the “coroutinex” library.
This works without kotlinx.coroutines
This is more or less what I was about to go figure out how to respond, and you beat me to it. Well done!
When I read threads like this I feel like I fell into a Bizzaro Universe where the simplicity of a C for loop with its explicitly exposed initialization, looping condition and next iteration stepping, without any hidden costs that you have to “keep in mind” beyond what you write, is considered undesirable.
Only to be followed by “new improved” language constructs that go into a long discussion of Iterable vs Sequence vs range operations, to wind up with a lot more code and hidden implications that must be considered (instantiation of the full list being one, foreach being about 3x slower than explicit for loop is another).
The while loop does create equivalent code but the beauty of C-for syntax was to eliminate such ugly boiler plate in the first place.
Please, don’t tell me that you are confused by C-for loop’s complex syntax or difficulty of intuiting its operation. The examples of Kotlin code you provide speak volumes to your ability to handle complexity and grasp non-intuitive constructs.
Why not admit that elimination of some language features in Kotlin, even when necessitated by other concerns, is a regression not evolution, which we live with to enjoy real improvements it offers.
Justifying it with code that resembles “perl poetry” or “obfuscated C” compared to the elegance of a C for loop is trying to put lipstick on a pig.
Please, don’t tell me you’ve ever accidentally blown past the end of a C array and randomly written crap into memory.
All programming is about tradeoffs. On modern hardware, my preference is to favor constructs that protect developers from making dumb catastrophic mistakes.
For an entertaining explanation of why this other world is better see this video: https://www.youtube.com/watch?v=Gsfmfeb2XW8