Book: small improvement to a table to make it clearer

[royalstream]

This table is used as an example of four heap values where two of them got deallocated leaving a gap.
It also has stack variables.
Instead of four stack variables I propose three, that way there's no misleading connection between the number of stack variables and heap variables.
But more importantly: three of the four stack variables had the same name (y) which could be confusing to a beginner, I changed this as well.

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @steveklabnik (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[steveklabnik]

Hey @royalstream ;

Did you maybe miss some of the changes here? This is currently just modifying one of the entries in one of the tables, but not any of the examples or anything else. It's not super clear to me what exact changes you're proposing.

[royalstream]

Hi,

Yes, it's a very small PR. I was going to merge this commit into my previous PR that changed several files (improved highlighting for the source code) but it had already been reviewed and approved.

Anyway, here's the rationale.

This table explains the fact that heap memory can have gaps (from deallocated values). This is the way this table was:

Address	Name	Value
(230) - 1		5
(230) - 2
(230) - 3
(230) - 4		42
...	...	...
3	y	→ (230) - 4
2	y	42
1	y	42
0	x	→ (230) - 1

It had four variables on the stack, three of them with the same name.
One of the y is a pointer to the heap, the other two are not. Coincidentally there are two gaps on the heap from deallocated values. A newbie could misinterpret there's a relationship between the two y not pointing to the heap and the two deallocated heap values (especially because they share the same name). The newbie could also think that's why there are exactly four stack variables and four heap variables.

This is the table with my changes (no repeated variable names, unrelated number of stack and heap variables)

Address	Name	Value
(230) - 1		5
(230) - 2
(230) - 3
(230) - 4		42
...	...	...
2	z	→ (230) - 4
1	y	42
0	x	→ (230) - 1

[steveklabnik]

Ah, so here is part of my confusion: I thought this was in a section with a code example, so I was thinking to myself, "you can't just change the diagram without the code, what is going on?" But, embarrassingly, this is one without code, so this is super reasonable. I now see exactly what you're saying, and I agree. Thanks for your patience 😄

@bors: r+ rollup

[bors]

📌 Commit 519cc82 has been approved by steveklabnik

[bors]

💡 This pull request was already approved, no need to approve it again.

• There's another pull request that is currently being tested, blocking this pull request: std: Cache HashMap keys in TLS #33318

[bors]

📌 Commit 519cc82 has been approved by steveklabnik