Allow Self::N in Array Lengths

language design
1

I have code:

pub(crate) trait Data: Clone {
    const N: usize;

    fn to_floats(&self) -> [usize; Self::N];
    fn from_floats(floats: [usize; Self::N]) -> Self;
}

N is declared at compile time. Therefore at compile time the compiler should have enough information to know the size of the outputs of to_floats(), from_floats() and the size of the struct that impls this trait. Currently compiler throws error:

generic parameters may not be used in const operations
type parameters may not be used in const expressions

There is no reason not to support the code above. Could this be supported please?

1 Like
2

Here’s how you can find out more:

Compile the code on nightly, and you get a compiler error like this

   Compiling playground v0.0.1 (/playground)
error: generic parameters may not be used in const operations
 --> src/lib.rs:4:36
  |
4 |     fn to_floats(&self) -> [usize; Self::N];
  |                                    ^^^^^^^ cannot perform const operation using `Self`
  |
  = note: type parameters may not be used in const expressions
  = help: add `#![feature(generic_const_exprs)]` to allow generic const expressions

Follow up with adding the unstable feature in question, and now you get a warning:

warning: the feature `generic_const_exprs` is incomplete and may not be safe to use and/or cause compiler crashes
 --> src/lib.rs:1:12
  |
1 | #![feature(generic_const_exprs)]
  |            ^^^^^^^^^^^^^^^^^^^
  |
  = note: see issue #76560 <https://github.com/rust-lang/rust/issues/76560> for more information
  = note: `#[warn(incomplete_features)]` on by default

This interaction tells you 3 things:

  1. there are existing developments for allowing usage of const generics in this context, and they are already as far developed to be supported using an unstable language feature on nightly
  2. the feature is one considered “incomplete”; so certain use cases may result in problems such as compiler crashes or unsound code or the like. This state generally means that either the implementation is simply not finished yet (and it’s a complex / large feature); or that the design of the language feature turned out to be pretty difficult, perhaps the current approach has significant shortcomings, and there’s a need for further design and/or implementation work or possibly there might even be strong reasons to cut down an “incomplete” unstable feature and make it less powerful, which may or may not affect your use case
  3. the right place to start looking for much more specific information about it all is the linked tracking issue: Tracking Issue for complex generic constants: `feature(generic_const_exprs)` · Issue #76560 · rust-lang/rust · GitHub (that issue thread currently contains almost 200 replies already, so maybe the answer to some of your questions is already there)

If you’re interested in exploring alternative approaches to perhaps restructure your program in a way that doesn’t run into “generic parameters may not be used in const operations” errors, feel free to ask for help over on users.rust-lang.org :wink:

10 Likes
3

Tl;dr: adding reasoning about values to the type system is surprisingly difficult.

But this particular use case, the use of an associated const as a const generic argument, is a project goal this year, so things are progressing, albeit only at a prototype level for now.

8 Likes
4

This specific case is known as min_generic_const_args and there's a good description of it in this HackMD post.

It seems like there may be some issues with supporting it in general – the current plans involve requiring an attribute on the trait to require the relevant associated items (N in this case) to be defined only as a non-generic expression or a single use of a type parameter. I have a vague idea of why there might be problems if the attribute weren't present, but haven't yet managed to come up with a concrete demonstration of what would go wrong with the example Data trait (although return type notation might be relevant). In any case, I don't think there's "no reason not to support" the code in question – allowing it unrestricted might be impossible to implement, and/or might place constraints on how the type checker can work or on what features could be added to it in the future.

1 Like