Open vmishenev opened 6 months ago
👀
Why does val result = for { break 42 }
not return the type Int instead of Unit?
Concerning infinite loop with break
, what is the advantage of it being a Unit
expression instead of just a statement?
I don't know if the keyword is still up for debate, but personally I think loop
/repeat
is a better choice. I see the reasoning in the full proposal is that it doesn't require introducing a new keyword, and that using while
would make it look like the condition was missing. However, I personally have two questions:
for {}
also have the same problem of looking like the condition is missing?loop
or repeat
not make better sense when read out loud? Saying for... print Hello World
sounds a little strange, compared to normal use of for
, for every item print item.name
. I will admit that loop
is also a little strange (although perhaps slightly better), loop... print Hello World
, which is perhaps where repeat
would be useful, but unlike for
( which I personally am familiar with because of Rust), is not used in any mainstream language I know ofI don't know if the keyword is still up for debate, but personally I think
loop
/repeat
is a better choice. I see the reasoning in the full proposal is that it doesn't require introducing a new keyword, and that usingwhile
would make it look like the condition was missing
- @needlesslygrim
If the current version was Kotlin 0.x, I would've also suggested loop
instead. Sadly, there are already code out there which might use loop
or repeat
(well, it exists in the std lib already!) and that code would break on upgrade. This is due to the fact that keywords have higher precedence than methods.
Ah, that makes sense. Maybe if there's ever a Kotlin 2.0 :^)
Yeah I dislike for {}
because it gramatically makes no sense and is confusing. Love this idea in general but I wish it could be better english like repeat
or even forever
. Actually I wrote this method for myself a while ago:
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 forever {}
that it is an endless loop.
The main benefit of such a "loop syntax" is: val result = for { break 42 }
As Kotlin already has the ability to create constructs like demonstrated by @mgroth0 above, if the ability of returning (more like break
ing) a value isn't there, it is useless.
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 }`?
The reason why a construct like...
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 { ... } ?
using for { ... } doesn't seem to make sense for me
as there's nothing to loop through
there should still be ability of break
the difference between normal repeat and
infinite one is easily noticeable so this shouldn't
be a problem to only have break
in the infinite
one
This issue is for discussion of the proposal to add an infinite loop
for { ... }
. The full text of the proposal is here.