We shouldn't even try to resolve irrefutable patterns as constants

[Manishearth]

pub const bar: u8 = 1;
fn foo(bar: bool) { }

gives me a type error, because it resolves bar to the constant and then realizes it's the wrong type.

Resolving bar to a constant isn't something that will ever work anyway, because if you write something like

pub const bar: bool = true;
fn foo(bar: bool) { }

it will move on to the "refutable pattern in function argument" error.

We should just not attempt constant resolution for irrefutable patterns.

This is technically a language change -- code that would previously not compile will now compile. cc @rust-lang/lang

[Manishearth]

Really given this and #33118 (comment) I'm half convinced we should just epoch-break const patterns to have an explicit const instead.

[eddyb]

Note the difference between unhygienic old macros and hygienic new macros.
EDIT: this comment should probably have been made on #49679 instead.

[petrochenkov]

See #45050 and linked threads/issues.

The proper solution is to

• use macro hygiene
• if hygiene cannot be used yet (like in Don't use underscores in argument names for derive output #49676), use explicit disambiguation bar @ _ (bar is unambiguously a fresh binding), but this is currently conservatively disallowed because some issues need to be fixed first before shadowing of variants/consts with local variables is allowed.

Fixing #33118 (comment) is in my queue, but I didn't consider it high-priority because derives successfully worked for years with their little underscore mangling tricks.

[petrochenkov]

One horrible workaround that arguably relies on bug #33118 (comment) (please don' t use it)

const bar: u8 = 10;

fn main() {
    fn bar() {} // fn bar shadows const bar
    let bar = (); // OK, bar resolves to fn, fns can't be patterns
}

[Manishearth]

@petrochenkov Are you commenting on the correct issue? This one doesn't have to do with macros; it was found by attempting to fix a macro issue but really it's its own thing.

The question is, macros aside, should irrefutable patterns allow binding on constants at all?

[petrochenkov]

Are you commenting on the correct issue?

Yes.

The question is, macros aside, should irrefutable patterns allow binding on constants at all?

The previous decision was "Yes".

[Manishearth]

That ... seems to be deciding something else, that happened to impact this situation as well -- do we have reasoning for why this should be the case for constants?

[petrochenkov]

Ah, now I see what is the source of confusion.
Constructors of unit structs and variants are basically constants of their respective types - they are treated equivalently in patterns and expressions.

[Manishearth]

We could remodel it such that when you use such a variant or struct in a pattern it's matched as a variant, not a constant, and then disallow constants in irrefutable patterns. Sounds like it may require not insignificant refactoring.

IOW, this seems to be a limitation imposed by the current implementation of pattern matching, and not a limitation of language design.

[petrochenkov]

Yes, but why discern between them?
If you write let x = 10; you can still hit a type mismatch with random struct x; or enum E { x } even if constants specifically are not treated as patterns.

[Manishearth]

Because there the ambiguity makes sense -- you may indeed want to match on x the struct (I mean, it's useless in this case, but in a more complex pattern less so).

OTOH here there's no reason to do so, because it's going to error at a later stage anyway. The fact that the compiler errors early prevents it from falling back to a binding. There's no real ambiguity here, whereas there is in the struct x; case.