Disambiguate between () as type and as value in const generic arguments

[varkor]

#![feature(const_generics)]

trait Trait<const U: ()> {}

impl Trait<()> for () {} // error (expected const argument, found type argument)

I wonder if we can resolve the unit value correctly here (though maybe it'll require a small hack), because this is quite unfortunate.

[cramertj]

Note that impl Trait<{()}> for () {} works and that impl Trait<(5, 5, 5)> for () {} results in

error: expected type, found `5`
 --> src/lib.rs:5:13
  |
5 | impl Trait<(5, 5, 5)> for () {}
  |             ^ expected type

[jplatte]

Would this require going back to the initial idea of trying to parse generic arguments as either types or values, disambiguating at a later stage where we know whether the parameter is a const or a type?

[varkor]

@jplatte: this isn't going to be very convenient to fix. The problem is that we aren't going to be able to disambiguate until type-checking itself. (This is the same problem as the snippet below, which currently also fails, because it can't tell what X is by name resolution alone.) We're going to need to pass more information into type-checking to disambiguate later, yes, but I suspect it won't be straightforward. If you want to investigate, though, this (and the related examples) would be a really nice papercut to fix :)

#![feature(const_generics)]

struct X;

struct S<const X: u8>;

impl<const X: u8> S<X> {} // error: wrong number of const arguments: expected 1, found 0

[jplatte]

Okay so in cases we can't tell whether we've got a type or a value during parsing, we need to try resolving both, correct? Is that already done or is value resolution only done if type resolution fails?

[varkor]

The problem is that () (and X in the above example) will resolve correctly in both the type and value namespace (as the two namespaces don't collide). We can't tell at resolution which is intended: we need type information for that. Currently for names (e.g. X), value resolution is only attempted if type resolution fails, so types take precedence.

[jplatte]

Yeah, that's what I was thinking. So we'll need to keep around both a resolved type and a resolved value in cases like the one you showed above.

And in cases where something can't be resolved (at all or in the right namespace) but the number of arguments given is still correct, I guess we will need yet more information to produce a reasonable error message.

[lcnr]

@rustbot claim

[petrochenkov]

Is it useful to disambiguate between () type and () value in generic argument?

The disambiguation is done for IDENT type vs IDENT value only because it's a super common case, so we can afford paying for it with more complexity and special cases. I'm not sure this is the case for ().

[varkor]

It makes the language more consistent, though it's definitely a less useful case than with identifiers. Let's see how much additional complexity it adds to support this case, and if it seems disproportionate, then we can re-evaluate.

[lcnr]

@rustbot release-assignment

[varkor]

I think at the very least we need to improve diagnostics here for min_const_generics, though I would prefer a complete solution.
(Alternatively, maybe unit type will/should be disallowed for min_const_generics.)

[lcnr]

I think we disallow unit rn, so that's the easier solution 😆

[varkor]

Yes, if we don't have compound data types at all, it doesn't make sense to have unit anyway.

[varkor]

This is essentially the same problem as getting multi-segment paths working with const generics (#66104 (comment) and Zulip conversation), which really would be useful to allow.

[lcnr]

visited during project-const-generics triage, added to rust-lang/project-const-generics#42 but don't expect us to make much progress here.