# 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 ## generic constants - unused substs - **Potential Solution**: only consider generic parameters explicitly mentioned and predicates only containing generic parameters which are explicitly mentioned when typechecking anon consts. - behavior may be surprising, e.g. - self referential where clauses - eval without first checking where-clauses - we currently do not eval if there are inference vars because of this. ## impls - constraining generic parameters `impl<const N: usize> Trait for UsesOption<{ Some(N) }> {}` - *exhaustiveness: `mpl Trait<true> for ()` and `impl Trait<false> for ()` implies `impl<const B: bool> Trait<B> {}`* ### unification - want to avoid accidentally stabilising desugarings by allowing things to unify that desugar to the same thir/mir/whateverweuse - `inner(outer(N))` has to unify with `inner(M)` with `M = outer(N)` for gce to be composable. i.e. we have to "split" constants - valtrees and padding - not necessary if only named constants are allowed, no need to split stuff. - *partial eval: `X + (1 + 2)` should unify with `X + 3`* - *associativity: `N + 2` with `M + 1` and `M <- N + 1`* - *commutativity: `1 + N + 1` with `N + 2`* ### Const evaluatability bounds ### const evaluatable unchecked future compat lint
Last changed by  
 
Rust Const Generics Project Group
Rust Const Generics Project Group
243

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
evaluatable bounds are fun uwu

We cannot ignore CTFE failures of constants used in the type system An impl like this is considered exhaustive 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.

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