New Ownership Part 2 Lecture #50
Conversation
week5/downgrade-mutable.md
Outdated
There was a problem hiding this comment.
Is this supposed to be a supplement or are we actually talking about this during lecture?
There was a problem hiding this comment.
Good question! We're not presenting the Downgrade slides, but I saved them in downgrade-mutable.md in case we add it back.
My reason for leaving them out was not timing concern (5 slides, about a minute or two) but its placement w.r.t the rest of lecture.
(1) The current placement of Downgrade isn't ideal, since it increases forgetting between when we introduce the concept "x can only take R..." here and call upon it here
Mutable References - introduces "x can only take R..."
[Optional] Downgrading Mutable References
Example: Fixing a Safe Program - calls upon "x can only take R..."
(2) If we discuss downgrading, ideally we provide an example of how understanding this concept can prevent common bugs. Also, I wonder whether students need to understand it to the low-level extent of RWO permissions, as opposed to high level "Cool, if you create an immutable reference, then the previous mutable reference is downgraded to immutable." I don't have an example as of now
There was a problem hiding this comment.
Actually, since we can add 20 minutes more content, this can be among the topics we discuss
|
I timed this to be 20 minutes, so definitely can add more content. Edit: I added the Struct Double Free example after "Motivating Ownership," since it directly makes use of the idea that owners == stack frames |
jespiron
force-pushed
the
ownership-part2
branch
from
3a9a85e to
ef37a8e
Compare
|
|
||
|
|
||
| # Today |
There was a problem hiding this comment.
You can just say Ownership Revisited here too, no strong feelings about it
| Today, we'll provide another way of thinking about ownership: | ||
|
|
||
| * Our goal: Transform ownership from a mysterious ruleset into an elegant problem-solving technique |
There was a problem hiding this comment.
Our goal: Transform ownership from a mysterious ruleset into an elegant problem-solving technique
Is this actually what this lecture teaches? I definitely agree with the 3 bullet points below but I'm wondering if this is a bit flowery for what we are actually saying
There was a problem hiding this comment.
Please reword it however you like
Ideally some foundation for these questions
Today we're going to address these questions:
- How do ownership rules prevent memory safety issues?
- What makes the borrow checker reject seemingly safe code?
| # The Catch | ||
|
|
||
| Getting code to compile is one thing. Understanding why is another. |
|
|
||
| * Sometimes we follow the rules blindly | ||
| * Missing the principles, repeating mistakes |
There was a problem hiding this comment.
Maybe instead of "Missing the principles, repeating mistakes" it could be:
When we break the rules, we may not fully understand why it is a problem
|  | ||
|
|
||
| We have a 15GB vector? |
|  | ||
|
|
||
| Inspired by the stack |
There was a problem hiding this comment.
Add colon at the end
| - Local variable "owned by" stack frame | ||
| - One stack frame (owner) per variable | ||
| - Dropped on function return |
There was a problem hiding this comment.
I think it is fine to have the "sound familiar" as a bullet point on the previous slide, I actually found the rewording here to be a bit confusing
week5/ownership_p2.md
Outdated
|
|
||
|  | ||
|
|
||
| * Each value in Rust has an _owner_ | ||
| * Owner is stack frame | ||
| * A value can only have one owner at a time | ||
| * When the owner goes out of scope, the value will be _dropped_ | ||
| * Deallocate the value here | ||
| * Safe because only one owner | ||
|
|
||
| <!--Speaker note: | ||
| One owner at a time | ||
| Emphasize that v is grayed out in diagram | ||
| => ownership transfer | ||
| --> |
There was a problem hiding this comment.
Is it possible to break this into 2 slides? The first slide can have all of this text, and the next slide can have only the text necessary to help describe the image?
| struct Warrior { | ||
| name: String, | ||
| score: u64 |
There was a problem hiding this comment.
add comma at the end of u64 and a newline in between the struct def and main (try to use rustfmt guidelines for all code blocks in slides as well)
|
Ok, I added outline.md |
|
Resuming at #62 |
Recovered from #41