Change:
<ins> // run-pass #![feature(const_generics)] //~^ WARN the feature `const_generics` is incomplete and may cause the compiler to crash #[allow(dead_code)] struct ArithArrayLen<const N: usize>([u32; 0 + N]); // ok #[derive(PartialEq, Eq)] struct Config { arr_size: usize, } struct B<const CFG: Config> { arr: [u8; CFG.arr_size], // ok } const C: Config = Config { arr_size: 5 }; fn main() { let b = B::<C> { arr: [1, 2, 3, 4, 5] }; assert_eq!(b.arr.len(), 5); } </ins>

Discussion:
Environment: The code: gives ICE:
Reproduces without the feature gate enabled.
It is noteworthy (and probably a bug too), that it only works if you use . My code below does ICE on stable, but not on nightly, but emits an error: Backtrace:
Just for the sake of maybe helping to drill down on the cause of the bug by way of comparison, here's an example of similar code that's somewhat more complex but that interestingly does work fine:
The backtrace is not too useful as it shows the reporting code rather than the code that raised the error. I did a little bit of debugging and I think raises the error in this code:
Adding some debug prints, I see that the is something like . Is there a way to resolve this "CFG" to the actual const struct so that I can select the field?
shouldn't really cause an error, it should be silent and simply leave the constant unevaluated (until a later situation in which the const parameter is replaced with an actual value).
I have the same panic but with a different code: Backtrace: rustc version:
i built a . it seems like doing any calculation in array sizes causes that ICE.
as a workaround you can do the calculations outside of the array and encapsulate the array in a different type, like in this .
This is a legitimate error, but it shouldn't have been ICEing. I'm sorry I didn't notice it earlier! The reason the original example shouldn't compile is because it can cause post-monomorphization const-eval failures! The should have a bound which effectively forces all use sites to evaluate the constant and ensure it has no errors (but this is not yet implemented - the syntax should do this).
Given the lack of const expression unification, this is what it would take: Note that the bound doesn't need to use as the element type, as long as it passes the same parameter as the actual use in a field type. This might require coordination with to make sure the WF semantics here are coherent with the rest of WF.
Thanks for showing a way forward The previous pull request did in fact not resolve the issue for me. So we need to construct a wrapper around the arr_size? i don't quite understand why/what that does. Is there somewhere to read up on it? just to avoid cargo culting.

specifically whats the difference to and what does the "empty" where clause do.
So there's a few things going on: we have a bit of a messaging issue (cc you never have to write braces around the array length expression, works just as well (the braces aren't for const generic params specifically, they're for expressions in paths, e.g. ) (or , same thing) and , where is a const generic parameter name, will not rely on a const expression, but let the typesystem see that a const parameter is used there, so in your example isn't useful OTOH, an expression like or is currently treated opaquely (because we have no algorithm to unify two such expressions), so if you write it twice, the compiler doesn't know it's the same one, hence using a type alias to write it only once
I've opened an issue about the first observation (), but there are definitely going to be learnability problems with the latter two until we address it properly.
This issue should be addressed in (though the code in the original post will not be accepted).
so its kinda like my ? the rules around when you need to be using brackets are kinda... , but thats probably a different issue all together.
Yes, this is These examples should all work (and hopefully will do soon!).