-
Notifications
You must be signed in to change notification settings - Fork 363
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Infinite loop #364
Comments
👀 |
Concerning infinite loop with |
I don't know if the keyword is still up for debate, but personally I think
|
If the current version was Kotlin 0.x, I would've also suggested |
Ah, that makes sense. Maybe if there's ever a Kotlin 2.0 :^) |
Yeah I dislike inline fun forever(op: Op) {
contract {
callsInPlace(op, AT_LEAST_ONCE)
}
do op() while (true)
} And I really like the way it looks, because it is crystal clear when you write |
The main benefit of such a "loop syntax" is: As Kotlin already has the ability to create constructs like demonstrated by @mgroth0 above, if the ability of returning (more like So I would propose to change this to loop constructs: // returns either a string if broken or null if the condition is false or no more entries.
val result: String? = while(cond) { break "str" }
val result: String? = for(i in sequenceOf()) { break "str" } The reason why a construct like val result: Int = for (i in sequenceOf<Int>()) {} else 1 won't work, is because of these breaking cases: for (i in sequenceOf<Int>()) if (true) else {} // is it `for ... else` or `if else`?
if (true) for (i in sequenceOf<Int>()) else {} // is it `if ... else` or `if { for ... else }`? |
That's true. I guess in this case we would need to force the user to insert the brackets. Making them returning nullable is also an option. Either is OK to me. |
maybe instead of for we could use repeat { ... } ? |
The proposal to use |
I do agree with this, and although it may be difficult to work around due to pre-existing code, I feel that introducing a new loop construct would be better. I recently tried Go, which uses To fix the problems around pre-existing code, maybe some kind of compiler flag could be introduced to allow use of the |
If we can solve the compatibility issue, I'm glad to have More agressively, we can |
I know this idea gets floated every once in awhile and never gets anywhere, but I think that it would make more sense to improve Kotlin's ability to build such functionality in the language. ~~When I say that, I'm thinking about the idea of allowing operator overloading of The only real reason to introduce this as a language concept is to gain break and continue. And the only real reason to name it
Another approach that I'm starting to like more as I think about it, could be to support break and continue as special union error types that could be specified on inlined lambdas, or as flags on lambda types that automatically introduce the union type at the invocation site. The more and more I think about this, this method sounds really simple to implement in the compiler. While I want the capabilities of this feature as much as the next guy, and often find myself introducing an arg-less |
This issue is for discussion of the proposal to add an infinite loop
for { ... }
.The full text of the proposal is here.
The text was updated successfully, but these errors were encountered: