Question about const evaluation

compiler
1

There is that issue for generic const expressions that some consts may fail to compute. Solution I see everywhere is for user to make a bound that constant evaluated successfully. Example of failure may be an overflow when adding two const. Can't we just issue a compiler error at the exact moment any failure like this happens? This way all other code would assume all constants are well formed. Probably there won't be some orphans consts that fail to evaluate but we never use them: when we would want to use them it would anyway require a bound, and it is generally a hazard go have bugs (which const evaluation failures are) to just be there until used anywhere (and compilation anyway stops on unmatching bounds).

And secondly, if there really is a reason to keep failed constants, why not just make "well-formed" bound implicit?

2

This is in the same vein as "why do we need to write trait bounds? Can't we just issue a compiler error at the exact moment any failure like that happens?"

Where yes, we could, and it'd even be useful sometimes, but one thing about Rust that people often like is that that doesn't happen. C++ templates generally work that way, and people are often happy to not have those associated problems in Rust.

So it's a question of how to make those tradeoffs and how to pick where things work in which ways.

7 Likes
3

OTOH it's already possible to do without it via post-monomorphization errors, const bounds get unwieldy more easily than type bounds, and even type bounds get very unwieldy sometimes.

4

I think what could be useful is a way to convert between bounds and post-mono errors. Then people who want more flexibility can opt-in - but know what they're getting into.

Perhaps something like this?

// library crate
pub fn concat<T, const N: usize, const M: usize>(input: ([T; N], [T; M])) -> [T; {N + M}]
where
    terminates { N + M }
{
    unsafe { transmute(input) }
}

// usage elsewhere
const PREFIX: [u8; 128] = [ ..... ];

fn with_prefix<const M: usize>(payload: [u8; M]) -> [u8; const_assert_terminates {128 + M}] {
    concat((PREFIX, payload))
}
5

You might be interested in this comment I wrote up around inline const, since I don't necessarily disagree: Stabilise inline_const by nbdd0121 · Pull Request #104087 · rust-lang/rust · GitHub

1 Like
6

Another thing I observed when writing code like this is it leaks implementation details and nothing can be changed without a breaking change. My bounds were huge, every layer was copying old bounds + added new which is O(layer^2), and not like with traits, but with exact computations. So in the end it is not the library doing computation, but the user doing them manually in bounds. And if somewhere deep some arithmetics change, all layers need to be updated, breaking all.

Generally that "terminates" for consts seems like a huge blocker to implement on the rustc side and huge ergonomics issue on user's side.

2 Likes