Why do some people confound &[T] with stack memory?

1

Hi guys

A question just popped into my mind and I was wondering if anyone else was thinking about this.

It seems like I am seeing this particular misconception from time to time on this forum.

Vec<T> saves its contents on the heap, while the contents of &[T] are on the stack.

The second part is not true since the &[T] doesn't care where the memory it points to lives.
For example

let owned: Vec<i32> = vec![1, 2, 3, 4, 5, 6];
let borrowed:  &[i32] = &owned[0..5];

borrowed will now point to heap memory, not to stack memory because Vec allocates on the heap.

Now I wonder. Where might this misconception come from? And do you also see it from time to time or is it just me?

2

I usually read it as, "Vec<T> puts its contents on the heap, while &[T] may be on the stack."

It's easy to miss typing "may." It's hard to say whether that implies a fundamental misconception or if it's just imprecision of language. It may be a mix of both.

5 Likes
3

Yes, I see things like this occasionally. I think there are these factors in play:

  1. When references are first introduced, all the simple relevant examples demonstrate borrowing values that are on the stack. So, one can think “& is for borrowing data from the stack”.
  2. A common error is to try to classify all types into “types that live on the stack” and “types that live on the heap”. If one tries to apply this incorrect model and hears that ”Vec<T> creates a heap allocation and &[T] does not”, and one is not yet practiced in distinguishing between a pointer and what it points to, one could conclude that &[T] doesn't ever involve the heap.

In my experience, (2) itself — stack types vs. heap types — is a more generally common confusion than this particular one about slices.

9 Likes
4

To complicate things further:

  • The compiler is allowed to elide heap allocations.
  • The compiler can transform code where references are taken into code without; code with &x might be compiled to something that only ever stores (values related to) x in registers, or might eliminate x entirely.
  • There are other kinds of memory besides stacks and heaps (e.g. a memory-mapped file).
  • async functions blur the distinction between stack and heap; a future might be created on the stack but later pinned on the heap.
1 Like
5

I always thought The Book's explanation of ownership was a bit "stack vs heap" heavy. For example:

types such as integers that have a known size at compile time are stored entirely on the stack, so copies of the actual values are quick to make. That means there’s no reason we would want to prevent x from being valid after we create the variable y. In other words, there’s no difference between deep and shallow copying here, so calling clone wouldn’t do anything different from the usual shallow copying, and we can leave it out.

Rust has a special annotation called the Copy trait that we can place on types that are stored on the stack, as integers are

They haven't talked about references yet. The "stored entirely on the stack" phrasing is probably because their goto non-Copy example is String.

The next couple of pages then introduce references and slices. They do correctly demonstrate a &str pointing into a String's data. But they don't talk about Copy and they don't talk about stack-vs-heap structure any more. Even though, say, a &str and a String have very similar structure. They should talk about why &str is Copy despite being structured like a String.

(&mut _ and reborrowing is a bit more complicated. But deserves to be talked about too!)

I don't know if this is the source of much misunderstanding, but I have always thought the heavy emphasis on the heap was a bit weird. Maybe the slice section could also be extended with some summarizing examples and explanation, like a shared slice pointing into static memory, an array, and some heap data.

1 Like
6

Why introduce the stack at all? The quoted text is inaccurate (integers can be stored as the elements of a Vec, or in registers, etc.) And [u8; N] is Copy even for large N.

3 Likes
7

I think because they talk about how stuff in functions go out of scope, but that's just me trying to read their minds.

Your point about types not caring where they "live" is also a good one.

8

Also, there is often a trade-off between accuracy and education. For example, when I correct my toddler that the Sun is actually not moving, but we are rotating. That's wrong, the Sun is moving, but arguably less wrong than his impression. (I once tried to give him the full explanation, but halfway through he ran away to play with his trains.)

Not that readers of the Rust book are toddlers, but the principle generalizes in my experience.

21 Likes
9

Unfortunately that book had a lot of inaccuracies, and at least one year ago they typically refused to knowledge and fix it. I found that a bit sad for such a popular book. But now they have a new, friendly maintainer, so it might make some sense to post these old issues again. For example, after one year, and after some others have confirmed it, they finally acknowledged one of my reported issues -- an issue that have been there for 7 years at multiple locations :-). See Wrong use of the term "shadowed" · Issue #3773 · rust-lang/book · GitHub

10

This is beautiful! I've nominated this for the quote of the week. Hope you don't mind.

1 Like