[Pre-RFC] pseudo-closures

[Nokel81]

Would it ever be possible for either of the following to be possible in the rust language because I feel that it could help with conciseness.

Example 1: returning from parent function in a “non-moveable” closure construct

fn foo (c_vec: Vec<C>) -> Result<Vec<D>, ErrorType> {
    c_vec.into_iter()
        .map('static |c| {
            if let Ok(d) = D::try_from(c) {
                d
            } else {
                return 'static ErrorType::new();
            }
        })
}

I know that the above example is a bit contrived but I have had instances in the past where something like this would have really help but instead I had to use other forms of iteration.

---

Example 2: using continue and break as “closures”

let list: Vec<Option<_>> = ...;
...
for item in list.iter() {
    ...
    foo.bar(item.unwrap_or_else(continue));
}

I know that it is possible to write the second as an if statement.

[draxdyn]

This post was flagged by the community and is temporarily hidden.

[matt1985]

Can you find a non-contrived example? I know that Scala (as well as other languages) have non-local returns,so you may be able to find examples there.

Also,it’s not very clear what the first example means,it reads to me as doing a local return from the closure.

[Nokel81]

The first example is doing a return either from the closure or from foo. Basically, it is trying to convert each item in the vector from a C to a D and if any fails then it returns some error from the outside function. The equivalent code in today’s rust is as follows:

fn foo (c_vec: Vec<C>) -> Result<Vec<D>, ErrorType> {
    let mut res = vec![];

    for c in c_vec {
        if let Ok(d) = D::try_from(c) {
            res.push(d);
        } else {
            return ErrorType::new();
        }
    }

    res
}

[scottmcm]

Example 1: returning from parent function in a “non-moveable” closure construct

Probably not, see

pre-RFC: Allow return, continue, and break to affect the captured environment

The general idea is that inside a closure, return; would return from the defining function instead of the closure. fn main() { // `return` would be a divergent expression and return from `main` let id: i32 = "321".parse().or_else(|| return); } This would allow Rust to satisfy the Tennent’s Correspondence Principle. In short, Tennent’s Correspondence Principle says: For a given expression expr, || expr should be equivalent. You could wrap arbitrary parts function body (even the whole f…

Example 2: using continue and break as “closures”

Same problem. Use try_fold instead of fold, and similar, instead.

[matt1985]

If the error types match,you can do this:

fn foo (c_vec: Vec<C>) -> Result<Vec<D>, ErrorType> {
    c_vec.into_iter()
        .map(|c| D::try_from(c) )
        .collect()
}

If the error types don’t match,you can add .map_err(|_| ErrorType::new() ) inside map.

[H2CO3]

it could help with conciseness

Maybe, but for sure it would incur a big penalty in terms of readability, exactly because it introduces non-locality.

[matklad]

A nice property of this style of “closures” is that they compose with control flow constructs, like ? or aync, nicely.

A good example here is Kotlin: because map,filter and friends for collections are implemented using “inline lambdas” (which are macros, semantics-wise), you can just call suspend functions from map over array list. Conversely, you can’t call suspend functions from mapping over lazy Sequences, because that uses a real lambda.

EDIT: to clarify, I don’t think we need this feature in Rust.

[eaglgenes101]

What you’re suggesting are continuations (or rather, a subset of them), which I admittedly have been championing for in the long term. That said, any continuation mechanism that lands in Rust will have to have an answer to how they preserve local reasoning, which your suggestion is lacking.