Add const evaluatable `where const { <block> }`

Proposal

Currently, the type system supports type-level equalities through the use of Peano numbers and type-level booleans. Thus, it’s possible to be able to gate certain functions to integers at compile-time using type-level shenanigans, but this makes it difficult to build readable APIs. Thus, there has been a long-time suggestion to have where blocks that allow for const evaluatable expressions such as where { N > 2 }, that would essentially be syntactic sugar. They would be much easier to write than type-level expressions.

It would be the most convenient to integrate these directly with existing syntax. Thus, it would be best to simple make these blocks identical to const { }. One key difference is that it would seem crucial that these const blocks would be populated with the const-generic parameters of the enclosing environment, which would differ from existing inline-consts (I believe). Specifically the final syntax would look like:

fn example<const N: usize, M: u32>() -> () where const { N == 3 }, const { N < (M as usize) } {
    ()
}

Motivation, use-cases, and solution sketches

This is specifically trying to solve the problem of having unreadable const APIs, as well as having to mangle with the type system to get compile time bounds. I’m not sure if that inline-consts are complete, but if so the main component would be adding in a ProjectionBound for consts that checks that it evaluates to true before compilation.

Links and related work

While I’m not aware of any specific const block in a language, the Eiffel programming language has preconditions, which can be thought of as conceptually similar except this is at compile time.

Initial people involved

I’m planning on working on this myself.

What happens now?

This issue is part of the lang-team initiative process. Once this issue is filed, a Zulip topic will be opened for discussion, and the lang-team will review open proposals in its weekly triage meetings. You should receive feedback within a week or two.

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

[nikomatsakis]

I’m going to close this issue since we’ve revised our initiative process and are phasing our MCPs. Viable next steps at this point are either to prepare an in-tree experiment (if there is an experienced Rust developer and a lang-team member willing to serve as liaison) or to start drafting an RFC.

In this case, there is already some active experimentation taking place around const generics which we haven’t fully “retconned” into the process. 😃 My impression overall is that we still need a good “vision” around const generics in terms of defining what we’re using it for and getting consensus around how it should feel. I myself have a lot of skepticism about the idea of “const evaluatable” from a user’s perspective, although I don’t have a better idea about how to solve the problem.

[scottmcm]

One key difference is that it would seem crucial that these const blocks would be populated with the const-generic parameters of the enclosing environment, which would differ from existing inline-consts (I believe).

FWIW I consider that “just” a not-implemented-yet. And https://rust-lang.github.io/rfcs/2920-inline-const.html#generic-parameters says it’s “for now”. So I wouldn’t worry about that difference.