[adt_const_params] consider to avoid using specialization when implement traits for Foo<const B: Bar>

Not sure this should be a lacking in RFC or a bug in compiler, sorry if I issued to the wrong place.

The title is a little confusing, here is an exmple for illustating:

#![feature(adt_const_params)]

#[derive(PartialEq, Eq, ConstParamTy)]
enum Number {
    Int,
    Float,
}

struct PropWrapper<const N: Number> {}

trait Prop {
    type Ty;
}

impl Prop for PropWrapper<{Number::Int }> {
    type Ty = usize;
}

impl Prop for PropWrapper<{Number::Float }> {
    type Ty = f32;
}

struct Foo<const N: Number> {
    n: <PropWrapper<N> as Prop>::Ty,
}

As you can see, I listed all the possible trait implementations Prop for types of PropWrapper (in this case, two possible types), but the compiler still complains:

error[E0277]: the trait bound `PropWrapper<N>: Prop` is not satisfied
  --> src/main.rs:29:8
   |
29 |     n: <PropWrapper<N> as Prop>::Ty,
   |        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `Prop` is not implemented for `PropWrapper<N>`
   |
   = help: the following other types implement trait `Prop`:
             PropWrapper<Number::Float>
             PropWrapper<Number::Int>

Currently my workaround is to use specialization:

impl<const N: Number> Prop for PropWrapper<N> {
    default type Ty = ();
}

This is unnecessary and the default case will never hit.

Is it reasonable for the compiler to check if all possible implementations are all listed for the case of using adt_const_params?

I use the nigthly build rustc 1.77.0-nightly (f688dd684 2024-01-04)

Start with the standalone src/main.rs reproducer and the reported nightly behavior for adt_const_params, then investigate how trait resolution handles the listed const-parameter implementations. Done means determining whether exhaustive implementations should avoid the need for specialization and documenting or validating the resulting compiler behavior.