How to let a Rust function propagate state?

Question

I need to write a Rust function that can modify state defined in a higher function and propagate it from one function call to another in an iterator (see the pseudo-code below).

In bad C, I would do it using a shared pointer. Of course, I understand why I should not do that, and why I can not do it in Rust.

The workaround I found is to add an extra function parameter and an additional return argument:

fn f(inputs ..., s) {
    let mut s = s;
    // computations that rely on the value of s
    // ...
    outputs ..., s
}

fn main() {
    let mut s;
    for ... {
        let (outputs ..., x) = f(inputs ..., s);
        s = x;
    }
}

This seems a bit heavy in terms of programming style and I hope that there is a lighter construction (maybe more monadic), I imagine using closures. How I should write it is not obvious to me.

I didn't understand anything, please try to be more precise, you want return more than one value by function ? — Stargateur, Dec 25 '18 at 19:13
I agree with stargateur, could you please clarify the question. If you want to return some value and use that value in the next iteration you can take a look at the usage of the fold like this [example](https://stackoverflow.com/questions/29548819/how-do-i-sum-a-vector-using-fold) — Akiner Alkan, Dec 25 '18 at 19:18
*Of course, I understand why I should not do that, and why I can not do it in Rust.* — please share with us why it's so obvious that you "should not" do this and provide code that shows that you "can not" do it. — Shepmaster, Dec 26 '18 at 20:45
What may not be clear in my post is that the inputs and outputs of the function could rely on IOs in the for loop, but this is not the case for s: it's just about sharing a mutable value between function calls! Sébastien Renauld's first reply answers my question in a rusty way, I was probably thinking in first place of something a little more functional and a bit off topic ... — Yvan Sraka, Dec 27 '18 at 09:45

Sébastien Renauld · Accepted Answer · 2018-12-26T21:56:40.957

The answer lies in references.

A shared pointer in C comes with caveats as to where and when it is okay to do so, and when it isn't. Rust has a borrow checker to make sure that you're not doing anything stupid/unsafe with pointers to prevent a large part of the issues people get bitten by in C.

For instance, consider a slight variation your code (made purely so it compiles). One can rewrite it as follows:

fn do_with(s: &mut u8, item: u8) {
    *s = *s + item;
}
fn main() {
    let mut s: u8 = 0;
    (1..10).for_each(|item| do_with(&mut s, item));
    println!("{}", s)
}

You'll recognize this syntax from C, but it is a lot safer than C as the borrow checker ensures that your code only ever has one mutable reference at any given time. As a result, the code is considered sane at every step and compiles.

You can also do it the way you did, by effectively trampolining the value from call to call. However, that does lead to less readable code and one more level of indirection. Example below:

fn do_with(s: u8, item: u8) -> u8 {
    s + item
}
fn main() {
    let mut s: u8 = 0;
    (1..10).for_each(|item| s = do_with(s, item));
    println!("{}", s)
}

In C, the danger in pointers mostly lies in upkeep and maintenance regarding them. As Rust checks and enforces this for you (and this - positively - prevents you from shooting yourself in the foot whenever you're using futures), making this largely a non-issue.

I disagree that the second example is "less readable" or "one more level of indirection". I do think that using `Iterator::for_each` is a misstep in this case. — Shepmaster, Dec 26 '18 at 20:38

How to let a Rust function propagate state?

1 Answers1