In the graphics programming I've done as a hobby, if I have a struct that contains a buffer for an image (say 1024px x 1024px = a buffer array of length 1048576), and have functions that operate on that buffer, etc, I either have to:

1) Create a Vec (separate allocation)

2) Make 1024 or 1048576 a global constant that every relevant struct and function references directly (whole program must use the same size at once; forget about exposing it as a library)

With const generics I can make all that code generic over the buffer resolution, meaning I can trivially use multiple different versions within the same build, without doing extra allocations, and I could even expose that code as a library for others to use at whatever resolution they wish

This is, literally, the exact same reason I use const generics. I was so excited when I started using them on Rust beta and could shave off some allocations!

You're allocating a megabyte on the stack?

Does rust have compile time protection against stack overflow? (... and what about recursion? is the stack dynamically resized at runtime?)

I'm allocating a megabyte inline. I can put the containing struct on the heap if I need to (I may be doing that; can't remember), but I don't want that to be the concern of the struct itself.

For example: what if I decide at some point to create a Vec of this struct? I don't want each of those elements then also putting their internal buffers into separate allocations on the heap, when the Vec itself is already on the heap. I want the struct to be as "flat" as possible, and to only allocate for the sake of the stack as a final step when the use-case demands it

We do not, runtime mitigation only (stack probes).

Recursion can blow your stack.

Thanks for the answer.

In emulators I often have to implement various FIFOs with a fixed word size (8 bits, 16bits, 32bits etc...) and depth (16, 32 or 64 elements etc...).

I could very easily make the word size generic, but not the depth. So I either had to make the depth dynamic (pretty expensive if you have hundreds of thousands of FIFO operations per second) or hack around it somehow.

Now I can just make the depth a generic parameter.

You can also abuse these types of generics to force the compiler to generate specialized versions of some methods in order to get better performance (at the cost of binary size) without having to manually create a bunch of variants of the same code.

Not OP, but my use case is serializing an array. Implementations were provided by the library for serializing arrays of `T` for lengths 0 through 31. I had an array of `[T; 32]`, so i couldn't serialize my array.

With const generics, the library provided implementations for all `[T; N]`, so my code worked out of the box with no headache.

> other than using them in array literals

Well, array literals are very convenient in some areas.

Matrix types can be cleaned up across projects, one widespread area being 3d graphics. Previously, you either had to create a separate type for each matrix size, or use a backing vector (of vectors); the first solution is ugly (because of redundancy), the second is potentially underperformant (in cases where one wants to avoid dynamic allocations as much as possible).