3 ms·

The reason is that `map`, `for_each` and the rest are not syntax and take closures. Closures in any language do not affect the control flow of their containing

The reason is that `map`, `for_each` and the rest are not syntax and take closures. Closures in any language do not affect the control flow of their containing function. These two annoyances could be resolved with: - async iterators https://github.com/rust-lang/rust/issues/79024 https://github.com/rust-lang/rust/issues/79024 - an extension trait for iterators over results: https://crates.io/crates/iterr https://crates.io/crates/iterr

NegativeLatency 4y ago
> Closures in any language do not affect the control flow of their containing function. In ruby returning from a proc will return from where the proc was defined, usually resulting in a bug https://stackoverflow.com/a/2325630 https://stackoverflow.com/a/2325630
pwdisswordfishc 4y ago
They do in Kotlin. Sometimes, anyway.
anon291 4y ago
it could also be resolved by a proper effect system.
ohgodplsno 4y ago
They can! Kotlin provides the crossinline modifier on closures, which are allowed to return in their parent scope. While making Iterable<T>.map take a crossinline function is not the wisest idea, it has values in cases like Option<T>, allowing you to write something along the lines of optionList.map { option -> val result = option.getOrElse { Log.d("Well that's fucked up") return@map null } ...more logic } and further in, result will not only have early returned, but will also have the proper, unwrapped type.
firstlink 4y ago
> Closures in any language do not affect the control flow of their containing function. This isn't true, and it's a damn shame that it is so close to being true. The biggest feature I miss from Common Lisp is that closures capture blocks and tags, and this is but the simplest form of cross-function control flow available in PL design. Algebraic effects are the next big thing.

NegativeLatency 4y ago

> Closures in any language do not affect the control flow of their containing function. In ruby returning from a proc will return from where the proc was defined, usually resulting in a bug https://stackoverflow.com/a/2325630 https://stackoverflow.com/a/2325630

pwdisswordfishc 4y ago

They do in Kotlin. Sometimes, anyway.

anon291 4y ago

it could also be resolved by a proper effect system.

ohgodplsno 4y ago

They can! Kotlin provides the crossinline modifier on closures, which are allowed to return in their parent scope. While making Iterable<T>.map take a crossinline function is not the wisest idea, it has values in cases like Option<T>, allowing you to write something along the lines of optionList.map { option -> val result = option.getOrElse { Log.d("Well that's fucked up") return@map null } ...more logic } and further in, result will not only have early returned, but will also have the proper, unwrapped type.

firstlink 4y ago

> Closures in any language do not affect the control flow of their containing function. This isn't true, and it's a damn shame that it is so close to being true. The biggest feature I miss from Common Lisp is that closures capture blocks and tags, and this is but the simplest form of cross-function control flow available in PL design. Algebraic effects are the next big thing.