Why do underscore prefixed variables exist?

Question

I am learning Rust, and came across the fact that adding an underscore at the beginning of a variable name will make the compiler not warn if it is unused. I am wondering why that feature exists, since unused variables are frowned upon.

Answer 1

I can see several reasons:

• Your are calling a function that returns a #[must_use] type, but in your specific case, you know you can safely ignore the value. It is possible to use a _ pattern for that (which is not a variable binding, it's a pattern of its own, but this is probably where the underscore prefix convention comes from), but you might want to document why you ignore the value, or what that value is. This is particularly common in tests in my experience.
• Macros. A variable created in a macro may or may not be used later. It would be annoying to not be able to not be able to silence warnings in a macro call. In this case there is a convention of doubling the underscores, this is enforced for example by clippy's used_underscore_binding lint.
• RAII. You might want to have a variable exist for its destructor side effect, but not use it otherwise. It is not possible to use simply _ for this use-case, as _ is not a variable binding and the value would be dropped at the end of the statement.

Answer 2

Here are some examples as to why you might want the behavior of ignoring an unused variable. Consider _s in the following function.

fn add_numbers(f: i32, _s: i32) -> i32 {
    f + 1
}

The _s variable makes it so we can keep the signature the same even if we haven't implemented it. This also works if we found out we didn't need the _s but because our library is used in so many different projects we didn't want to change the API to our function. This may or may not be bad practice but could be useful in a situation where _s needs to stay and not do anything. We could also use _ here but _s potentially has more meaning as to what the variable is for in the future.

The next place where this can be useful is when a type implements Drop and you care where that logic happens. In this example you can see that the _result variable is needed so that the Drop happens at the end.

fn main() {
    let mut num = 1;
    // let _ = try_add_numbers(&mut num); // Drop is called here for _
    let _result = try_add_numbers(&mut num); // without the _result we have a warning.

    println!("{}", num);
    // Drop is called here for the _result
}

// keep the api the same even if an aurgument isn't needed anymore or
// has not been used yet.
fn add_numbers(f: i32, _s: i32) -> i32 {
    f + 1
}

// This function returns a result
fn try_add_numbers(i: &mut i32) -> Result<GoodResult, GoodResult> {
    if *i > 3 {
        return Err(GoodResult(false));
    }
    *i = add_numbers(*i, 0);
    Ok(GoodResult(true))
}

struct GoodResult(bool);

impl Drop for GoodResult {
    fn drop(&mut self) {
        let &mut GoodResult(result) = self;
        if result {
            println!("It worked");
        } else {
            println!("It failed");
        }
    }
}

If we use let _result = try_add_numbers(&mut num); we have a variable that is in scope until the end of main and drop will be called then. If we had used let _ = try_add_numbers(&mut num); we still don't get a warning but drop is called at the end of the statement. If we use try_add_numbers(&mut num); without a let binding we get a warning. The output of this program does change depending on which we use with our try_add_numbers function.

It worked
2

or

2
It worked

So there is a use for both _ and _named variables which need to be chosen based on what the output of your programs needs to be. Play around with my example on the playground to get a feel for it.