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:

• You 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.
• Function parameter: You might have to name a parameter because it's part of your API, but don't actually need to use it. Anonymous parameters were removed in the 2018 edition.
• Macros. A variable created in a macro may or may not be used later. It would be annoying 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 not be dropped at the end of the enclosing block as with variable binding.

Answer 2

Just define type of the variable i.e

for example:-

  fn names(){ //this case the function gives an warning like "help: if this is intentional, prefix it with an underscore: `_myname`"
      let myname = "yash";  
      }

so by latest changes in your code, you can do to overcome this error:-

  fn name(){ //here warning won't come
     let myname: &str = "bash"
       }
 

Answer 3

• let a is a value binding, and a stack space will be allocated to store it's value.
• let _a is something behaves like let a. In addition, it is marked as intentional, so that compiler will not pop up a warning if _a is not used.
• let _ is a pattern, and _ is a reserved identifier which cannot be used elsewhere. This will not cause a stack space to be allocated, so the value on the right side of = will be released soon after this statement.

Here is a example: Playground

pub struct Node {
    value: usize,
}

impl Drop for Node {
    fn drop(&mut self) {
        println!("drop() {}", self.value);
    }
}

pub fn square() {
    let a = Node { value: 1 };
    let _a = Node { value: 2 };
    let _ = Node { value: 3 };

    println!("Hello, world!");
}

fn main() {
    square();
}

the output is:

drop() 3
Hello, world!
drop() 2
drop() 1

You can read this to learn more

Answer 4

I stumbled here through Google while looking up this warning related to match variables. This is tangentially related.

Sometimes you may have code where you get a Result and want to match on the cases, but you don't care about the error value. Instead of using _e or something, you can actually just use _ which explicitly doesn't bind. Here's a concrete example. We don't care about the value of the error since we're returning our own.

fn some_method() -> Result<u32, MyCustomError> {
    // ...
    let id: u32 = match some_str.parse() {
        Ok(value) => value,
        Err(_) => return Err(MyCustomError::Blah)
    };
    // ...
}

Answer 5

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.