Associated const equality conflicts with associated type equality

[mversic]

I tried this code and it compiled:

trait Trait2 {}

trait Trait1 {
    const A: u32;
    type A;
}

impl<T: Trait1<A = u32>, const N: usize> Trait2 for [T; N] {}

fn main() {}

Then I tried this code and it didn't compile:

#![feature(associated_const_equality)]

trait Trait2 {}

trait Trait1 {
    const A: u32;
    type A;
}

impl<T: Trait1<A = 12>, const N: usize> Trait2 for [T; N] {}

fn main() {}

Meta

rustc --version --verbose:

rustc 1.72.0-nightly (37998ab50 2023-06-11)
binary: rustc
commit-hash: 37998ab508d5d9fa0d465d7b535dc673087dda8f
commit-date: 2023-06-11
host: aarch64-apple-darwin
release: 1.72.0-nightly
LLVM version: 16.0.5

Backtrace

error: expected associated type bound, found constant
  --> src/main.rs:10:16
   |
10 | impl<T: Trait1<A = 12>, const N: usize> Trait2 for [T; N] {}
   |                ^^^^^^
   |
note: associated type defined here
  --> src/main.rs:5:5
   |
5  |     type A;
   |     ^^^^^^

error: could not compile `proba2` (bin "proba2") due to previous error

Explanation

Rust allows for associated const parameter and associated type parameter to have the same name. So, I expected there would be some way to disambiguate which one I'm referring to when setting the equality constraint but haven't found a way to do so.

This problem is related to Associated Const Equality

[fmease]

Added T-compiler since this particular code could be accepted by making the AssocKind passed to trait_defines_associated_item_named dependent on the term kind (type or constant) of the binding in <dyn AstConv<'_>>::add_predicates_for_ast_type_binding. Edit: That's not quite correct but close.

Added T-lang since in the future, we might want to allow Trait<Const = path::to::Const> (i.e., allowing the user to omit the curly braces and allowing paths to resolve to either type or const) in which case, it would very much become ambiguous.

[Jules-Bertholet]

Perhaps a const prefix could be required to disambiguate? (T: Trait1<A = u32, const A = 16>)

[mversic]

IMHO I would disallow types and consts to have the same name as in this example:

trait Trait1 {
    const N: u32;
    type N;
}

since this is not allowed:

trait Trait1<N, const N: usize> {}

but that would be a breaking change

[fmease]

That could be left for a future t-lang discussion. I've already got a fix locally since we can always continue to require curly braces for paths
&co as the RHS of assoc const bindings to rule out ambiguities.

Forbidding assoc consts & types if they're identically named would be pretty inconsistent, they live in different namespaces after all. Further, assoc const equality bounds are pretty niche, no reason to add special cases just for them. What's more, while identically named assoc consts & types are relatively rare, the following code involving supertraits could come up in practice I'd argue:

trait A: B { type X;  }
trait B { const X: (); }

// A<X = { () }>

My patch is going to handle the case above as well.