# evaluatable bounds are fun uwu ## We cannot ignore CTFE failures of constants used in the type system An impl like this is considered exhaustive ```rust impl<const N: usize> Trait<N> for () { type Assoc = [u8; 32]; const ASSOC: usize = N; } ``` If we were to ignore `(): Trait<error>`, what are sensible values for the associated items of that type. ## pretty clear stuff - Without evaluatable bounds, errors during monomorphization are unavoidable - reaching the evaluation limit HAS to be a hard error and cannot be guarded against - same for recursion and size limits ## why are constants used in the type system special Constants used in expressions could simply `panic` on use. Constants used in the type system cannot be ignored when detected. ## questions, thoughts, other stuff - is there a difference between constants used in the type system and constants simply used in expressions? - generic constants in expressions are already allowed without evaluatable bounds - and instead with post mon oerrors which is dumb it should be a runtime panic - is it, why? - "soundness" if its an abort it will be fine... - or could just be done over an edition I guess..? idk - also, people rely on that behavior for soundness, so changing it seems hard - the why is because it means you cant ensure something is eavluated at compile time as an optimization without opting into a post mono error for code that might not actually even get run - I actually wrote why that is fine - gdi we should have writtin all of this down somewhere xd - just make it a lint, why hard error? - ~~people are stupid and silence lints they don't understand~~ ## previous discussions associated consts wf https://rust-lang.zulipchat.com/#narrow/stream/146212-t-compiler.2Fconst-eval/topic/associated.20consts.20const.20wf which builds on https://rust-lang.zulipchat.com/#narrow/stream/146212-t-compiler.2Fconst-eval/topic/const.20wf.20bounds.20implementation