# `WithOptConstParam` cycle diagram ```rust 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] { let x = Foo; x.foo::<{ 3 + 1 }>() // ^^^^^^^^^ called `constant` in the diagram } ``` Without `WithOptConstParam` we would get the following cycle: ```mermaid flowchart TD TypeckAnonConst["typeck(constant)"] OptConstParam["opt_const_param_of(constant)"] TypeckContext["typeck(context)"] EvaluateConst["evaluate `constant`"] TypeckAnonConst -- needs the expected return type --> OptConstParam OptConstParam -- resolve `foo` --> TypeckContext TypeckContext -- to unify `constant` with the return type --> EvaluateConst EvaluateConst -- requires the MIR of `constant` --> TypeckAnonConst ``` Using `WithOptConstParam` we get the following setup: ```mermaid flowchart TD subgraph TypeckAnonConst["typeck(constant)"] OptConstParam["opt_const_param_of(constant)"] CallTypeckConstArg["returned `Some(const_param)`"] end TypeckConstArg["typeck_const_arg(constant, const_param)"] OptConstParam["opt_const_param_of(constant)"] subgraph TypeckContext["typeck(context)"] EvaluateConstant["evaluate `constant`"] OtherStuff["other stuff"] end OptConstParam -- "to resolve `foo`" --> EvaluateConstant EvaluateConstant -- "requires the MIR of `constant`"--> TypeckConstArg TypeckConstArg -- "once finished" --> OtherStuff OtherStuff -- "once finished" --> CallTypeckConstArg CallTypeckConstArg -- "to only typeck `constant` once" --> TypeckConstArg ``` While this works, it does get a lot more complex when the anonymous constant contains closures or inline consts. Both of these things are luckily either unstable or not useful. ```rust struct Foo; impl Foo { fn foo<const N: usize>(self) -> [u8; N] { [0; N] } // ^ called `const_param` in the diagram } fn context() -> [u8; 4] { let x = Foo; // either THIS: x.foo::<{ const {1} + 3 }>(); // ^^^^^^^^^ called `child` in the diagram // ^^^^^^^^^^^^^ called `constant` in the diagram // or THIS: x.foo::<{ (|| 4)() }>(); // ^^^^^^ called `child` in the diagram // ^^^^^^^^^^^^^ called `constant` in the diagram } ``` ```mermaid flowchart TD TypeckAnonConst["typeck(constant)"] OptConstParam["opt_const_param_of(constant)"] TypeckContext["typeck(context)"] EvaluateConst["evaluate `constant`"] BorrowckConst["mir_borrowck(constant, const_param)"] BorrowckChild["mir_borrowck(child)"] TypeckAnonConst -- needs the expected return type --> OptConstParam OptConstParam -- resolve `foo` --> TypeckContext TypeckContext -- to unify `constant` with the return type --> EvaluateConst EvaluateConst -- requires the MIR --> BorrowckConst BorrowckConst -- relies on facts from nested items --> BorrowckChild BorrowckChild -- closures and inline consts rely on the parents typeck --> TypeckAnonConst ``` The issue is that, when calling `mir_borrowck` - or some similar query - for the `child`, we "forget" the const parameter for `constant` by entering a new query. Changing constants and inline constants to also always use `WithOptConstParam` to remember the relevant const parameter for their parent seems like quite a lot of effort. As this isn't a high priority I would prefer to wait for less hacky fix by improving the query system to deal with these cycles.
Last changed by  
 
Rust Const Generics Project Group
Rust Const Generics Project Group
1223

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
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
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