I am trying to create a user input validation function in rust utilising functional programming and recursion. How can I return an immutable vector with one element concatenated onto the end?

fn get_user_input(output_vec: Vec<String>) -> Vec<String> {
    // Some code that has two variables: repeat(bool) and new_element(String)
    if !repeat {
        return output_vec.add_to_end(new_element); // What function could "add_to_end" be?
    }
    get_messages_from_user(output_vec.add_to_end(new_element)) // What function could "add_to_end" be?
}

There are functions for everything else:
push adds a mutable vector to a mutable vector
append adds an element to the end of a mutable vector
concat adds an immutable vector to an immutable vector
??? adds an element to the end of a immutable vector

The only solution I have been able to get working is using:

[write_data, vec![new_element]].concat()

but this seems inefficient as I'm making a new vector for just one element (so the size is known at compile time).

CodePudding user response：

You are confusing Rust with a language where you only ever have references to objects. In Rust, code can have exclusive ownership of objects, and so you don't need to be as careful about mutating an object that could be shared, because you know whether or not the object is shared.

For example, this is valid JavaScript code:

const a = [];
a.push(1);

This works because a does not contain an array, it contains a reference to an array. The const prevents a from being repointed to a different object, but it does not make the array itself immutable.

So, in these kinds of languages, pure functional programming tries to avoid mutating any state whatsoever, such as pushing an item onto an array that is taken as an argument:

function add_element(arr) {
  arr.push(1); // Bad! We mutated the array we have a reference to!
}

Instead, we do things like this:

function add_element(arr) {
  return [...arr, 1]; // Good! We leave the original data alone.
}

What you have in Rust, given your function signature, is a totally different scenario! In your case, output_vec is owned by the function itself, and no other entity in the program has access to it. There is therefore no reason to avoid mutating it, if that is your goal:

fn get_user_input(mut output_vec: Vec<String>) -> Vec<String> {
//       Add mut  ^^^

You have to keep in mind that any non-reference is an owned value. &Vec<String> would be an immutable reference to a vector something else owns, but Vec<String> is a vector this code owns and nobody else has access to.

Don't believe me? Here's a simple example of broken code that demonstrates this:

fn take_my_vec(y: Vec<String>) { }

fn main() {
    let mut x = Vec::<String>::new();
    
    x.push("foo".to_string());
    
    take_my_vec(x);
    
    println!("{}", x.len()); // E0382
}

The expression x.len() causes a compile-time error, because the vector x was moved into the function argument and we don't own it anymore.

So why shouldn't the function mutate the vector it owns now? The caller can't use it anymore.

In summary, functional programming looks a bit different in Rust. In other languages that have no way to communicate "I'm giving you this object" you must avoid mutating values you are given because the caller may not expect you to change them. In Rust, who owns a value is clear, and the argument reflects that:

• Is the argument a value (Vec<String>)? The function owns the value now, the caller gave it away and can't use it anymore. Mutate it if you need to.
• Is the argument an immutable reference (&Vec<String>)? The function doesn't own it, and it can't mutate it anyway because Rust won't allow it. You could clone it and mutate the clone.
• Is the argument a mutable reference (&mut Vec<String>)? The caller must explicitly give the function a mutable reference and is therefore giving the function permission to mutate it -- but the function still doesn't own the value. The function can mutate it, clone it, or both -- it depends what the function is supposed to do.

If you take an argument by value, there is very little reason not to make it mut if you need to change it for whatever reason. Note that this detail (mutability of function arguments) isn't even part of the function's public signature simply because it's not the caller's business. They gave the object away.