Inconsistency: let mut _ = 0; is rejected by the parser when let mut _a = 0; is not

[nodakai]

fn main() {
    let a = 0;
    let _b = 0;
    let _ = 0;
    let mut b = 0;
    let mut _b = 0;
//    let mut _ = 0; // error: expected identifier, found `_`
}

• https://play.rust-lang.org/?gist=767161713daada788646&version=nightly

[KalitaAlexey]

_ is not a identifier. It is used to suppress result.

[petrochenkov]

This is correct, ref/mut can't be followed by an arbitrary pattern (like _), they expect a single identifier (like a or _a).

[bluss]

Here's an example that shows a clear difference between _ and _s (playground)

fn main() {
    let s = String::new();
    let _ = s;  // no op
    let _t = s; // move
    let _u = s; // ERROR: use of moved value
}

[nodakai]

Yes, _a is just a variable whose should_warn() happens to return false (librustc/middle/liveness.rs) wherease _ aka token::Underscore generates a placeholder pattern (PatKind::Wild.)
When parse_pat() (libsyntax/parse/parser.rs) finds mut in a let-binding, it accepts only a proper identifier.

Nevertheless I perceive the language design is inconsistent here and scarcely documented. Is it only me who think something has to be improved?

[nodakai]

@bluss Well, in fact let _a = 0; println!("{}", _a) has no problems.

    let _ = s;  // no op

This is surprising, but I might have seen a discussion on something like that long before, perhaps in relation to mem::drop()

[petrochenkov]

Is it only me who think something has to be improved?

Something may be improved, i.e. a custom error message can be issued, but I suppose specialized diagnostics need to be data-driven, i.e. targeted at people en masse and not individuals experimenting in the playpen in the search of consistency :)
How likely is this construction written accidentally by a person not familiar with the difference between patterns and identifiers? let _ = foo; - very likely, let mut _ = foo; - probably unlikely (I wish we had a way to measure these things somehow).

[petrochenkov]

I've added a bit more general diagnostic message in #32506