the const parameter `SIZE` is not constrained by the impl trait, self type, or predicates

[nazar-pc]

I tried this code:

#![expect(incomplete_features, reason = "generic_const_*")]
#![feature(
    min_generic_const_args,
    generic_const_args,
    generic_const_items,
)]

type const U32_TO_USIZE<const N: u32>: usize = const { N as usize };

trait Trait {}

impl<const SIZE: u32, T> Trait for [T; U32_TO_USIZE::<SIZE>] {}

I expected to see this happen: Code compiles with RUSTFLAGS="-Znext-solver=globally" cargo build

Instead, this happened:

error[E0207]: the const parameter `SIZE` is not constrained by the impl trait, self type, or predicates
   --> *.rs
    |
222 | impl<const SIZE: u32, T> Trait for [T; U32_TO_USIZE::<SIZE>] {}
    |      ^^^^^^^^^^^^^^^ unconstrained const parameter
    |
    = note: expressions using a const parameter must map each value to a distinct output value
    = note: proving the result of expressions other than the parameter are unique is not supported

Very similar code compiles:

trait Trait {}

impl<const SIZE: usize, T> Trait for [T; SIZE] {}

So compiler treating SIZE as unconstrained is clearly a bug.

I found a few bug reports with similar message, but they weren't exactly the same.

Meta

rustc --version --verbose:

rustc 1.97.0-nightly (9eb3be26b 2026-05-18)
binary: rustc
commit-hash: 9eb3be26b46eccea1de7448ea9cc3c1d20bb1a35
commit-date: 2026-05-18
host: x86_64-unknown-linux-gnu
release: 1.97.0-nightly
LLVM version: 22.1.4

[Morgane55440]

the error is correct and not a bug.
a stable analog would be;

trait Boxed {
    type InBox;
}

trait Trait {}

impl<T : Boxed > Trait for T::InBox {}

which does not compile.
it does not compile because if you have

impl Boxed for str { type InBox = Box<str>; }
impl Boxed for String { type InBox = Box<str>; }

then you would have two conflicting implementations of Trait for Box<str>.
if the compiler cannot deduce a generic parameters solely from the trait and the type, then said generic parameter is said to be unconstrained, and this is not allowed.

for example here, on a 16 bit system,it would not be possible to deduce what SIZE was used to define the implementation impl Trait for [u8;0]
indeed, both 0 and u16::MAX as u32 + 1 would be valid candidates.

moreover, the compiler is not allowed to look at what you have written for the definition of U32_TO_USIZE.
you could just as well have written

type const U32_TO_USIZE<const N: u32>: usize = const { 0usize };

and that would not affect what is considered constrained or not.
in this case it is even clearer that it is impossible to deduce what SIZE was used for impl Trait for [u8;0]
the correct solution would be to have a generic usize and use some form of USIZE_TO_U32 instead.

i will grant you that the fact E0207 does not cover the associated type case in its doc is pretty bad, as this is a common case of confusion.

[nazar-pc]

I don't think it makes a lot of sense to me as an end user. I have a generic constant, I have what is, essentially, a function that converts u32 to usize with some logic. It either returns usize or it panics at compile time (or it enters infinite loop and is aborted at some point).

Whether any of that happens depends on the call site, it doesn't need to be known beforehand, it is totally fine that not all u32 values are valid and is in fact possible that the constant will panic for certain invalid values.

For me it appears to be as constrained as plain const SIZE: usize would have been.

The fact that even this doesn't compile with the same error:

type const USIZE_TO_USIZE<const N: usize>: usize = const { N };

trait Trait {}

impl<const SIZE: usize, T> Trait for [T; USIZE_TO_USIZE::<SIZE>] {}

Is really disappointing.

In certain cases it is often desirable to use smaller than usize types, but not being able to cast back to usize results in awkward APIs that are not as misuse-resistant as they could have been.

[kpreid]

Besides the potential for overlapping impls, rustc also has to be able to, for a given type, answer the question “does this type implement this trait”, without reference to exactly how the type was spelled in the source code — anything else would be unsound. That is, there has to be a deterministic algorithm for answering the question “does [T; N] implement Trait?”.

So, if impl<const SIZE: u32, T> Trait for [T; U32_TO_USIZE::<SIZE>] were to be valid, rustc would have to be able to invert the function U32_TO_USIZE — for each N: usize encountered, find a SIZE: u32 value such that U32_TO_USIZE::<SIZE> == N (if one exists). It’s unlikely that Rust will ever include the functionality of inverting user-defined functions as part of type-and-trait-checking.

[Morgane55440]

here is how you could make it work

// NOTE : in the unlikely case that usize::MAX < u32::MAX,  u32::MAX as usize will always give usize::MAX, which is what we want
type const FITS_IN_U32<const N: usize>: usize = const { (u32::MAX as usize)-N  };
trait Trait {
    const SIZE32 : u32;
}

impl<const SIZE: usize, T> Trait for [T; SIZE] where [(); FITS_IN_U32::<SIZE>]: {
    const SIZE32 : u32 = SIZE as u32; // this will never oveflow thanks to the FITS_IN_U32 check
}