7

I get why they must have constant size, but I don't get why that size must be known at compile time. Even C allows variable length arrays on the stack. What does this limitation help Rust with?

Shepmaster
  • 388,571
  • 95
  • 1,107
  • 1,366
blue_note
  • 27,712
  • 9
  • 72
  • 90
  • 1
    See also [Why can fixed-size arrays be on the stack, but str cannot?](https://stackoverflow.com/q/54673145/155423); [Why is `let ref a: Trait = Struct` forbidden?](https://stackoverflow.com/q/36057645/155423); [What does “Sized is not implemented” mean?](https://stackoverflow.com/q/28044231/155423) – Shepmaster Dec 02 '20 at 17:28
  • 3
    *Even C allows* — C allows lots of bad things. The fact that a language allows something doesn't make it _good_. – Shepmaster Dec 02 '20 at 17:31
  • 1
    @Shepmaster: the question has to do with what is the technical reason for that choice, not about how useful VLAs seem – blue_note Dec 02 '20 at 17:37
  • 1
    Sure, but there has to be at least one good use for a feature, otherwise the technical reason could be "there's no good reason to support this". I'm not making a statement that VLAs are or are not useful, just that saying "C can do *X*" is a weak argument. – Shepmaster Dec 02 '20 at 17:43
  • 1
    @Shepmaster: it's only argues that it is *possible* to have sizes known at runtime – blue_note Dec 02 '20 at 17:47
  • 1
    "the question has to do with what is the technical reason for that choice, not about how useful VLAs seem" that VLA are terrible is a good technical reason for not having VLA in other languages. – Masklinn Dec 02 '20 at 17:47
  • 1
    @Masklinn: turns out it's being added to the language, so, that *was not* the reason, for rust developer team at least. – blue_note Dec 02 '20 at 17:50
  • 2
    C11 remove this feature for a reason :p – Stargateur Dec 02 '20 at 18:07
  • Seems to me a good reason is in a no-alloc (e.g. some no-std) environment where dynamic memory allocation isn't available, yet you want to be able to create a temporary buffer with the size known only at run time. Trivial to toss one on the stack in C, possibly infeasible in Rust (if this still hasn't been stabilized in 2022, that is). – Peter Hansen Oct 06 '22 at 14:43

1 Answers1

4

Even C allows variable length arrays on the stack.

C can relatively easily support this because of its trivial semantics.

When you have to call destructors/drop, this is far less trivial, so Rust didn't initially support it because it's effort to implement and doesn't give all that much of a benefit.

Eventually, Rust will support this (and already does on nightly) thanks to RFC 1909 — unsized rvalues.

trent
  • 25,033
  • 7
  • 51
  • 90
Sebastian Redl
  • 69,373
  • 8
  • 123
  • 157
  • 2
    *already does* — pedantically, not quite: ["VLAs are not implemented yet"](https://doc.rust-lang.org/nightly/unstable-book/language-features/unsized-locals.html#variable-length-arrays) – Shepmaster Dec 02 '20 at 17:32
  • 7
    *this is far less trivial* — I'd be interested to learn why the addition of destructors makes this harder; it's not an obvious leap for me. – Shepmaster Dec 02 '20 at 17:34
  • Just as an example, a VLA of `Drop` types needs to store the object count so that it can correctly iterate on drop. – Sebastian Redl Dec 03 '20 at 09:34
  • Wouldn’t it have to always store the object count to disallow out-of-bounds indexing (and thus memory unsafety) regardless of if the elements implement `Drop`? – Shepmaster Dec 03 '20 at 12:17
  • Hm, true. Frankly, I don't know the concrete pitfalls. I just remember from the time I worked on Clang that the other devs complained about having to support VLAs in C++. – Sebastian Redl Dec 03 '20 at 12:31