Cannot use _ for const arguments

[jonhoo]

I tried this code:

#![feature(const_generics)]

struct Foo<const N: usize>([(); N]);

fn main() {
    let x: Foo<_> = Foo([]);
}

I only half-expected the code to compile, given where const generics is at (is inference of const generic arguments even intended to eventually work?), but the resulting error was pretty jarring:

error[E0107]: wrong number of const arguments: expected 1, found 0
 --> src/main.rs:6:12
  |
6 |     let x: Foo<_> = Foo([]);
  |            ^^^^^^ expected 1 const argument

error[E0107]: wrong number of type arguments: expected 0, found 1
 --> src/main.rs:6:16
  |
6 |     let x: Foo<_> = Foo([]);
  |                ^ unexpected type argument

Meta

rustc --version --verbose:

1.44.0-nightly (2020-04-02 537ccdf3ac44c8c7a8d3)

[Centril]

[...] but the resulting error was pretty jarring:

The error is technically correct, but confusing indeed. What happens here is that (as I noted in the other issue you filed, #70753) _ is not interpreted as an expression, so it is interpreted as a type. Since you have a type inference variable, you get an error about wanting a const argument but having a type.

Instead, we would want to interpret _ in this case as a const inference variable. To do so, we would need to delay disambiguation until type checking by adding a variant ast::GenericArg::Infer and handle _ specially in the parser. This seems quite necessary to me.

cc the usual suspects, @varkor @petrochenkov @eddyb

[jonhoo]

Yeah, when I initially typed the issue up, I wrote "which, while technically accurate, is pretty jarring", but then decided it wasn't necessary :p

[lcnr]

Handling it in the ast is not actually enough afaict as we require type inference to know what kind of arg is required. So we probably have to update hir::GenericArg as well.

see #66615 (comment)

[jhpratt]

@Centril Foo<const _> would be unambiguous, correct? I'm not sure I particularly like it, but I think it would work. I ran into this when doing some impls, where it would actually be unambiguous regardless.

[varkor]

Foo<_> is unambiguous too and doesn't involve new syntax. It's just that it'll take a little bit more implementation work.

[lcnr]

implemented under feature(generic_arg_infer), tracked in #85077 (comment).

Closing this issue