owned this note
owned this note
Published
Linked with GitHub
# Const well-formedness and const equality
We currently only allow identity expressions as generic constants, meaning
that only `N` and `{ N }` is allowed while more complex expressions like `N + 1` and `std::mem::size_of::<T>()` are currently forbidden.
To resolve this restriction effectively we need to deal with both const well-formedness and const equality.
### Const well-formedness (const wf)
A monomorphic well-formed const can be successfully evaluated, so both `panic!()` and `loop {}` are not const wf while `1 + 2` is.
Only wf expressions are useable in types. An expression which is not wf results in a compile time error.
```rust
let _: [u8; 1 - 2];
//~^ ERROR evaluation of constant value failed[E0080]
```
What happens if a polymorphic constant is used in a type, e.g. `[u8; N - 1]`? This has been discussed in [#68436](https://github.com/rust-lang/rust/issues/68436#issuecomment-663190861) and in some other places.
For generic consts to be wf all concrete instances of a that const must be well-formed, see [const-eval/#49](https://github.com/rust-lang/const-eval/issues/49) for a complete definition.
This document was written with the assumption that requiring all generic consts used as part of the type system to be const wf is necessary.
Not doing so...
....implicitly leaks implementation details of functions and types:
```rust
fn foo<T>() {
let v: [u8; 64 / std::mem::size_of<T>()]; // This fails for ZST.
}
```
...causes hard to debug errors which won't be emitted with `cargo check`:
```rust
fn bar() {
foo::<1>(); // While the error cause is this call in `bar`...
}
fn foo<const C: usize>() {
let x = [u8; C - 2]; // ... the actual error will be emitted here...
}
// ...and improving these error messages is very difficult.
```
...implicitly stabilizes the way we monomorphize generic impls:
```rust
trait Foo {
fn foo(&self) {}
fn bar(&self);
}
impl<T> Foo for T {
fn bar(&self) {
let _: [u8; std::mem::size_of::<T>() - 1]; // This errors for ZSTs.
}
}
fn bound<T: Foo>() {};
fn main() {
().foo(); // Does this cause an error?
(&() as &dyn Foo).foo(); // Or this?
bound::<()>(); // Or this?
}
```
### Const equality
Right now we do not unify two distinct generic constants, even if they are identical expressions, meaning that the following function would not typeck:
```rust
fn foo<const N: usize>() -> [u8; N + 1] { // This `N + 1`...
[0; N + 1] // ...currently does not unify with this `N + 1`.
}
```
While this can often be worked around, it is still fairly restrictive.
Const equality will be used to implement const wf bounds, so we'll talk about them first.
## What should be done
The goal here is to get an MVP which does not restrict us from extending this in the future. This initial implementation requires two expressions to be identical for them to be considered equal.
The initial implementation will also be restricted to basic arithmetic, arbitrary function calls, and generic constants.
Allowing more complex expressions requires us to correctly deal with desugarings to prevent future compatability hazards. More detail about this and some examples can be found [here](https://hackmd.io/z7LKv6WKRkiw2WC7KDkvYw). That document also contains some infos on how this will be implemented.
To implement const well-formed bounds, we now use this equality relation to require every generic const to equate to a constant which is part of the public API and also propagate these bounds upwards.
```rust
/// `N + 1` is a generic const which is part of the public API
/// of this function, so this compiles.
fn ex1<const N: usize>() -> [u8; N + 1] {
todo!()
}
/// `N + 1` is not mentioned in the public API of `ex2` which
/// means that this results in an error.
fn ex2<const N: usize>() {
let _: [u8; N + 1];
//~^ ERROR generic constant not mentioned as part of the function signature or where bounds.
}
/// `N + 1` is mentioned in a where bound, so it is allowed inside of
/// this function as well.
fn ex3<const N: usize>() where [(); N + 1]: {
let _: [u8; N + 1];
}
/// `if true { N } else { 3 }` uses a conditional, so it is not allowed
/// as a generic constant.
fn ex4<const N: usize>() -> [u8; if true { N } else { 3 }] {
//~^ ERROR overly complex expression used in generic constant
//~| HELP consider moving that instruction into a helper function
//~| NOTE only basic arithmetic, function calls and generic constants may be used in generic constants
todo!()
}
const fn util5(n: usize) -> usize {
if true { n } else { 3 }
}
/// `util5(N)` is a function call whose internals can be arbitrary,
/// so this is allowed.
fn ex5<const N: usize>() -> [u8; util5(N)] {
[0; util5(N)]
}
/// We do not unify `N + 1` and `1 + N` for now, we may allow this
/// in the future though.
fn ex6<const N: usize>() -> [u8; N + 1] {
[0; 1 + N]
//~^ ERROR generic constant not mentioned as part of the function signature or where bounds.
//~| HELP found `N + 1`, but expected `1 + N`
}
trait Foo {
fn foo() {}
}
/// The same also holds for trait impls.
impl<const N: usize> Foo for [u8; N] {
fn foo() {
let _: [u8; N - 1];
//~^ ERROR generic constant not mentioned as part of the function signature or where bounds.
}
}
/// Mentioning the expression in the where bound of the
/// impl fixes this error, so this compiles.
impl<const N: usize> Foo for [u8; N] where [(); N - 1]: {
fn foo() {
let _: [u8; N - 1];
}
}
/// These bounds are also propagated upwards, so the following will fail...
fn ex7<const N: usize>() {
let _ = ex1::<N>();
//~^ ERROR the bound `N + 1` is not satisfied.
//~| HELP ...
}
/// ...while this will compile
fn ex8<const N: usize>() where [(); N + 1]: {
let _ = ex1::<N>();
}
/// Calling a function with const wf bounds with a more complex
/// expression requires the given wf bound with replaced terms.
fn ex9<const N: usize>() where [(); (N - 1) + 1]: {
let _ = ex1::<N - 1>();
}
```
We currently use `where [(); expr]:` as a way to add additional const wf bounds.
Once we have started experimenting with this it is probably worth it to add
a more intuitive way to add const wf bounds.
A possible syntax is `where (expr),`. This is not intended to be part of the
initial unstable implementation however.
