Hacker News Reader

Comment by oconnor663 | Hacker News Reader

The "you can't print arrays larger than 32" thing was a common papercut for beginners. You could usually work around it with slices, but until now that's been yet another thing to memorize on day 1 or week 1. It only takes a couple of papercuts to go from "this is challenging but fun" to "this is pointlessly frustrating", so I'm always very happy when one of the big ones gets fixed.

View on HN

Fortunately under normal circumstances it's almost always better to use a Vec anyway, and this is encouraged by the Book. Having done projects in Rust for the past ~2 years I didn't even know this limitation existed, because I hardly ever use plain arrays.

IMHO, it's a chicken and egg kind of thing; it's way easier to use Vecs because arrays really need const generics to actually be useful. I am interested to see how this balance changes.

I know for my no_std work, const generics for arrays can't come fast enough.

I have also felt the need multiple times.

Especially when passing a number of things to a function, and you need to pass ownership. You can't do that with a slice, because that's borrowed, so a Vec used to be the only option. Now there's a one option more that's going to be more lightweight than allocating a Vec :)

I've often used the `arrayvec` crate for things like this. Actually one of the things I'm most excited about, once const generics is ready, is seeing something like `arrayvec` in the standard library.

No it isn't! I'm sick of dealing with Vec's that do need to be a defined length to be valid, but could be any length! That's what a type system is for! But nobody uses the proper type for that, because actually working with the proper type is so awful!

It's the single worst aspect of working with Rust. I am very happy.

Const generics will fix all this; they can’t come a moment too soon, in my opinion.

Array sizes are static and can be used for optimization, that's a very significant advantage in some situations. As an example, if I'm emulating some RAM module of a console, I'd much rather use a cheap [u8; RAM_LEN] than a Vec that would incur all kinds of runtime checks for nothing.

Unfortunately there are many limitations with arrays in Rust at the moment, which make it more annoying than it should be. Generics over the array size is one of them, although unfortunately there are others such as https://github.com/rust-lang/rust/issues/53827

I would disagree. There are a lot of data types which are a fixed length array of bytes (e.g. encryption keys), which make more sense as a value, rather than a container type.

My impression may be biased by the types of projects I typically do. Pretty much the only time I ever use an array is for const data.

It gets really annoying on no_std, which makes me happy to see this making progress in the language.

Does Rust monomorphize const generics too? E.g. if I use 255 arrays with length 1-255.

Yes, I believe const generics get monomorphized just like normal generics, with the usual set of tradeoffs that implies.

OTOH, it's footgun-y because for each size you get a new different monomorphism of the formatting function, and you may end up with a lot of them.

I have no insight in the compiler, but wouldn't this be optimized away?

What about printing vectors? (array dynamically sized) What other kind of traits are useful for arrays?

Vectors can already be printed. Vectors types are only dependent on the contained elements, whereas Arrays types depend (until const generics come) both on the size of the array and the contained elements.

So whereas a generic implementation of Display for Vec of any length was possible, Arrays required one implementation of Debug per possible length of the array.

Reply on news.ycombinator.com