Drop break and continue control-flow keywords about dora HOT 5 CLOSED

One additional reason is that it prevents building pure library-defined resource handling:

Consider

fun use[R : Closeable, T](resource: R, function: T -> Unit) {
    function();
    resource.close();
}
while ... {
  use(someFile, |x| { printFile(someFile); if someFile.isEmpty() { break; } } );
}

"Use do ... finally ... in the use function" would be the obvious answer, but in the long term I'd like to adopt a Rust-like approach where exceptions are only used for fatal errors that require aborting the program.

Not having break, continue and exceptions for control flow would allow us to replace finally by a pure library implementation.

from dora.

Haven't looked at the PR so far.

Don't get your argument here though and would be curious what I am missing here: break/continue/return only work inside the current function or closure. So the example above would fail to compile (is there missing something?). How would you implement resource handling "as a library" in Dora?

from dora.

Feel free to substitute break with throw; but I agree with you that it is the least compelling point listed here. Feel free to disregard it.

from dora.

I don't get why break/continue are different in this regard. It seems that even return would break resource handling already. How would you otherwise ensure that the close-function is run (without finally or defer)?

from dora.

If the intended language semantics are that break/continue/return only work inside the current closure, then they can't cause this issue; then only throw remains. As mentioned, I withdraw the point, because it detracts from the three better ones.

from dora.