RFC for static generic parameters

[milibopp]

This is a rough draft to see whether something like this should be done. I'd appreciate feedback on how the technical details could look like, since I do not know a lot about the compiler internals myself.

[seanmiddleditch]

Other uses worth mentioning include the ability to define compile-time sizes of small buffers and other data-structures. Some data types need flexibility but they don't need it at a call site, or a call site knows enough of its domain to make optimization choices. See the various small_vector implementations for C++ that allow a user to declare some fixed-size array for storage so the container only needs to resort to memory allocation in the (intended to be unlikely) scenario that the small buffer wasn't large enough. These optimizations can have a lot of meaningful impact in practice given the relatively large cost of memory allocations for many application domains.

[SimonSapin]

Other uses worth mentioning include the ability to define compile-time sizes of small buffers and other data-structures.

For an example of this, see how Servo defines a bunch of SmallVecX types for various values of X:

https://github.com/mozilla/servo/blob/b14b2eca372ea91dc40af66b1f8a9cd510c37abf/src/components/util/smallvec.rs#L475-L525

[brendanzab]

I could be wrong, but this would probably require a dependent type system. This is far too big a problem to be tackled by Rust on top of all the other challenges it is taking on.

[nrc]

Technically this whole RFC is proposing dependent types (with or without the algebra). These algebraic expressions are just like constant expressions, and aren't anything like full dependent types in terms of complexity.

[milibopp]

Ah, so there is a technical term for this type system feature. Thanks for pointing that out. I've read a little more on that topic now and it looks like a full dependent type system is a bit of an overkill.

Having at least something comparable to what C++ provides would still be an asset though. Do you think that's possible?

[brendanzab]

By the way I'm very much in favour of generic static parameters, I just think it might be worth defining the limits of this proposal.

[dobkeratops]

i hope this goes through . fixed point arithmetic is another use case, also shift values for compressed/relative pointers

[milibopp]

I've included your feedback into the RFC.

[brendanzab]

Have you thought of using the static keyword to make this clearer?

fn add_n<static n: int>(x: int) -> int

[milibopp]

Yes. That would be my favourite alternative to the syntax proposed, if it is necessary or desired to mark these parameters. I should probably explicitly add this to the RFC.

[brendanzab]

Yeah I think it would remove any ambiguity. That way you would not need to know if int was a trait or type. int is easy, but user defined types could be more difficult.

[milibopp]

Hm… I mostly thought about distinguishing them visually, since the static parameters will be lowercase, while the type parameters are uppercase. But then if the trait bounds and static types look alike this becomes less clear. I guess it makes sense to change it.

[brendanzab]

Awesome!

I would also add that static generic parameters could be used for implementing range and mod types like in Ada as library types:

type Score is range 1 .. 10;
type Hours is mod 24;

[milibopp]

Done. I suspect that there are more things to think about in the detailed design section and it should probably be fleshed out in some more detail. But I am not entirely sure, how exactly to approach this, i.e. what kind of caveats and corner cases are still to be considered. Or is this already detailed enough for an RFC?

[matthieu-m]

Regarding arbitrary code execution during the compilation: did not Rust already jumped the gun with procedural macros ?

[emberian]

@matthieu-m that is true

[alexcrichton]

While desirable, a feature such as this has far-reaching interactions with the rest of the type system. The team has decided to postpone this to after 1.0, so I'm tagging this as postponed and closing for now.