# 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
Last changed by  
 
Rust Const Generics Project Group
Rust Const Generics Project Group
190

Read more

feature(not_so_min_generic_const_exprs)

summary This document should be considered an "extension" to lcnr's min_generic_const_exprs proposal. It builds off the proposal of only allowing const items (i.e. ADD:<usize, N, 1> instead of N + 1) by adding a desugaring of N + 1 and foo(..) to const items to allow nice user facing syntax for things that seem like they should "obviously" work. changes add AbstractConst variant to ty::ConstKind Instead of storing generic type level constants as ConstKind::Unevaluated we should add a ConstKind::AbstractConst and directly lower type level generic exprs to it instead of anonymous const items: enum ConstKind<'tcx> { Param(ty::ParamConst), Infer(InferConst<'tcx>),

8/4/2022
`WithOptConstParam` cycle diagram

struct Foo; impl Foo { fn foo<const N: usize>(self) -> [u8; N] { [0; N] } // ^ called `const_param` in the diagram } struct Bar; impl Bar { fn foo<const M: i32>(self) -> [u8; 3] { [0; 3] } } fn context() -> [u8; 4] {

5/26/2022
Evaluatable bounds: are they needed?

If we do not require a proof that generic constants are evaluatable we end up with errors during monomorphization, which is bad™ as these don't get detected by cargo check. Evaluatable bounds vs conditions TODO: Elaborate on the difference between evaluatable { N - 1 } and is_true { N > 0 }. It is not possible to rely on conditions to prevent errors during monomorphization by themselves, as it not possible for the compiler to prove that a condition completely covers the cases where some other constant panics. This is related to silent CTFE errors. Having a lint which suggests adding conditions for each potentially panicking constant is also very difficult, as the compiler does not look into functions for this. We also again have the issue that having the compiler figure out with which inputs something causes a panic is impossible. Defining evaluatable

5/4/2022
Const generics master doc

not strictly necessary things are marked with in italics. cc https://hackmd.io/dwO7dvv5RI-ob1d5P5QDQA?view adt const params structural equality opt in vs backcompat concerns function pointers

3/21/2022
Read more from Rust Const Generics Project Group
Published on HackMD