Inconsistent move tracking

[bfops]

This builds fine:

struct Foo;

fn bar<'a>(foo: &'a mut Foo) -> &'a mut Foo {
  { let _ = foo; }
  foo
}

But changing _ to _bar causes it to fail:

struct Foo;

fn bar<'a>(foo: &'a mut Foo) -> &'a mut Foo {
  { let _bar = foo; }
  foo
}

fn main() {
  bar(&mut Foo);
}

<anon>:5:3: 5:6 error: use of moved value: `*foo` [E0382]
<anon>:5   foo
           ^~~
<anon>:5:3: 5:6 help: see the detailed explanation for E0382
<anon>:4:9: 4:13 note: `foo` moved here because it has type `&mut Foo`, which is moved by default
<anon>:4   { let _bar = foo; }
                 ^~~~
<anon>:4:9: 4:13 help: if you would like to borrow the value instead, use a `ref` binding as shown:
<anon>:    { let ref _bar = foo; }
error: aborting due to previous error
playpen: application terminated with error code 101

https://play.rust-lang.org/?gist=93507eb0a792a0d7842d&version=stable

[steveklabnik]

Hmmmmm. _ gets dropped immediately. I wonder if that has anything to do with this.

[hanna-kruppe]

I think this is intended. Inside of a more complex pattern, it makes sense not to move: https://play.rust-lang.org/?gist=ba031030dfb06a18cf6b&version=stable

If this is intentional, it needs to be documented though. I didn't find anything in the reference (only that _ is not an identifier), and it regularly surprises people including myself.

[bfops]

It makes more sense in the context you link, but it's definitely incredibly confusing in the original context. It looks a lot like an explicit attempt to drop in let _ = foo;, especially if let _bar = foo; does it.

The special treatment of _ has messed with me on many an occasion. It would be nice if it were equivalent to _new_unique_id_234234. If the user wants immediate drop, they can use drop(foo), can't they?

[steveklabnik]

I think that it feels like a special case if you look at let _, but in more complex patterns, it makes more sense. But that's a gut-level feel.

[hanna-kruppe]

_ does not "drop immediately", it does not bind the value in the first place. Only in the context of let _ = <some temporary> that means the temporary is dropped immediately afterwards because, well, it's a temporary and not moved into a variable.

[huonw]

This behaviour is somewhat unfortunate in this case, but it is basically "required", for _ to be handled uniformly elsewhere. For example, some examples that don't (and shouldn't, IMO) move values are

let tuple: (u8, String) = (...);

let (x, _) = tuple;

match tuple {
     (0, _) => { ... }
     (1, ref y) => { ... }
     _ => { ... }
}

Something somewhat similar would be possible if we allowed, for instance, let (x, ref _) = tuple... but this isn't quite the same (it borrows tuple, and so disallows later moves/mutations in that scope).

Since we're not touching parts of the tuple that need moving, we don't have to move tuple. This means _ is a special pattern (similar to Haskell), and, as @rkruppe says, doesn't drop anything immediately, it literally just does nothing with the argument. However, this is an easy mistake to make, because let _ = foo(); is often used to ignore results that aren't needed, and in this case the return value of foo is dropped immediately... but only because _ doesn't bind anything and so that let is the same as just foo();, except for warnings.

The _foo convention for silencing warnings is just that: a convention. _foo is a perfectly valid identifier, and can be used later (unlike _): let _foo = 1; println!("{}", _foo); compiles.

(I have this feeling that we either had, or tried to have, _ behave more like _foo in the past... and it didn't stick.)

Closing as not a bug, but thanks for filing!