Chapter 15: Smart pointers #407

steveklabnik · 2017-01-17T23:00:20Z

This isn't done yet, but it's a start.

parir

I just checked for typos.

parir · 2017-01-20T13:40:16Z

src/ch15-00-smart-pointers.md

+That is, they have extra capabilities that references don't, hence the "smart"
+nickname.
+
+You've already encounted a few smart pointers in the book, we didn't call them


s/encounted/encountered

parir · 2017-01-20T13:40:37Z

src/ch15-00-smart-pointers.md

+nickname.
+
+You've already encounted a few smart pointers in the book, we didn't call them
+that by name, though. For example, in a certian sense, `String` and `Vec<T>`


s/certian/certain

parir · 2017-01-20T13:42:50Z

src/ch15-00-smart-pointers.md

+Most of this should look familliar: a struct, a trait, a main function. There
+is one tricky bit: like we said in chapter 13 on Iterators, the `type Target =
+T;` syntax is "associated types", which is covered in Chapter 20. Don't worry
+about it too much, it is a slightly different way of delcaring a generic


s/delcaring/declaring

parir · 2017-01-20T13:44:01Z

src/ch15-00-smart-pointers.md

+The first two are the same, except for mutability: if you have a `&T`, and
+`T` implements `Deref` to some type `U`, you can get a `&U` transparently. Same
+for mutable references. The last one is more tricky: if you have a mutable
+reference, it will also coerece to an immutable one. The other case is _not_


s/coerece/coerce

parir · 2017-01-20T13:44:14Z

src/ch15-00-smart-pointers.md

+`T` implements `Deref` to some type `U`, you can get a `&U` transparently. Same
+for mutable references. The last one is more tricky: if you have a mutable
+reference, it will also coerece to an immutable one. The other case is _not_
+possible though: immutable references will never coerece to mutable ones.


s/coerece/coerce

carols10cents · 2017-02-02T01:27:11Z

src/ch15-00-smart-pointers.md

+```rust,ignore
+enum List<T> {
+    Cons(T, List<T>),
+    Nil,


Ok soooo I know it's usually called Nil in lisp, but wdyt about calling this variant Empty instead, to avoid confusion with "i thought Rust didn't have nil?!?!" Just a thought, I don't feel super strongly about this.

carols10cents · 2017-02-02T01:27:58Z

src/ch15-00-smart-pointers.md

+type `SomeEnum<T>`, so we need to figure out how much memory a `SomeEnum<T>`
+needs. Let's look at..." into infinity. In order to figure out how much memory
+`SomeEnum::A` needs, we need to figure out how much memory `SomeEnum::A` needs.
+It's impossible to know!


omg i got the point after like 2 iterations of this :P

carols10cents · 2017-02-02T14:33:06Z

src/ch15-00-smart-pointers.md

+        make `main::List` representable
+```
+
+Because a `Box<T>` is a pointer, we always know what size it is: a `usize`.


We've talked about usize being the type of an index, but I don't see that we've explicitly said "usize is how big pointers are"-- do you think this would be a good spot to say that? if so, I'm happy to add something in my pass through :)

carols10cents · 2017-02-02T14:35:12Z

src/ch15-00-smart-pointers.md

+```
+
+We use `*y` to access the thing that `y` refers to, rather than `y` itself.
+Here's an example of overloading `*` using `Deref`:


Why would we want to overload Deref like this? When shouldn't we overload Deref?

carols10cents · 2017-02-02T14:38:22Z

src/ch15-00-smart-pointers.md

+### `Deref` coercions.
+
+There's one other trick with `Deref`: it's one place where Rust will do
+automatic coercions. Consider this code:


Hm I wouldn't call Deref the "place" where Rust will do automatic coercion-- the place is function arguments, as opposed to uhh what are the places that people expect automatic deref and it doesn't happen? I forget.

I would reword this as "There's one other trick with Deref and function calls: Rust will do automatic coercion using Deref on arguments passed to functions" or similar, wdyt?

check the RFC on this

carols10cents · 2017-02-02T14:41:52Z

src/ch15-00-smart-pointers.md

+
+The ability to run some code when something goes out of scope is very powerful.
+For example, here's something that looks similar to a box. This code won't
+_work_, but it illustrates the concept:


I would reword "This code won't work" as "here's some pseudocode that assumes we have functions allocate_memory and free_memory that implement a custom memory allocator" (is that the only reason it won't work?)

carols10cents · 2017-02-02T14:42:57Z

src/ch15-00-smart-pointers.md

+So first, we declare `MyBox<T>` to have a reference to some data. We can't use
+actual `&T` references for this, we'd use `*const T`, but we won't talk about
+*raw pointer*s until Chapter 20. So for now, pretend that this works; it's the
+same idea.


hnnngg i see, ok. This seems like a lot to handwave over :-/ What if we show a socket that we call code to close on Drop instead?

Agreed that an example that a) doesn't work, b) looks forward to chapter in the future is maybe a bit much. Something that's a little more real-world and builds on what they know (socket sounds good, yeah) sounds like it might be a better fit here.

carols10cents

Had some time so I decided to review what you've got so far, I've got a few questions that if you clear up for me what your intentions are, I can probably fix the text when I take my pass through :)

gypsydave5 · 2017-02-21T21:21:08Z

src/ch15-00-smart-pointers.md

+
+You've already encounted a few smart pointers in the book, we didn't call them
+that by name, though. For example, in a certian sense, `String` and `Vec<T>`
+are both smart pointers. They own some memory, and allow you to manipualate it.


s/manipualate/manipulate

gypsydave5 · 2017-02-21T21:25:05Z

src/ch15-00-smart-pointers.md

+12: it manages a file handle that the operating system gives us.
+
+Given that this is a design pattern in Rust, this chapter won't cover every
+smart pointer that exists. Many libraries will build their own, as well, and


s/own, as well/own as well

steveklabnik · 2017-02-22T19:56:14Z

@carols10cents @jonathandturner this is ready for a review! 🎊

steveklabnik · 2017-02-22T19:59:34Z

oh, for the cycle thing, i took an example from here https://www.reddit.com/r/rust/comments/34dy5z/reference_counted_cycles/cqtsbkt/?st=izhduq8s&sh=f47a5d42

we should give them some kind of shout-out

sophiajt

Sections up to RefCell feel pretty good with some nits and some areas for polish.

RefCell and some of the sections after feel like they need a tighter narrative. There feels like a fair amount of "this stuff is hard, and complicated" but I think that we could lead the reader through understanding how this stuff works so that they can write their code successfully.

I think we could tighten it up a bit. I mention not having the Cell section at all, which I think could work since we don't use it much after that section.

I think it's important to talk about cycles, though something like Rc<RefCell> feels perhaps like it's something also we could mention but not spend as much time on. Yes, some code definitely uses it, but I'm thinking about complexity budget for this chapter and how much the reader can hold in their heads. If we remove a few things from the last few sections and focus on working with the patterns like interior mutability and working around cycles, we're doing pretty good, I think.

sophiajt · 2017-02-22T21:49:26Z

src/ch15-00-smart-pointers.md

+So what are smart pointers, anyway? Well, we've learned about references in
+Rust. "Pointer" is a generic term for something like a reference, that is,
+pointers "point at" something else. References are a kind of pointer that only
+borrows data; in many cases, smart pointers *own* the data that they point to.


Needs better linking phrase to set up comparison.

sophiajt · 2017-02-22T21:59:05Z

src/ch15-00-smart-pointers.md

-Heap allocated
-Express Ownership of a heap allocated thing
+Just like any value that has ownership, when a box goes out of scope, it will
+be dealloacated.


s/dealloacated/deallocated

sophiajt · 2017-02-22T22:01:57Z

src/ch15-00-smart-pointers.md


-The three situations to use Box
+It turns out that putting a single value on the heap isn't very useful, so you
+won't use boxes very often. When do you need a box? When you want to ensure


I think you mean something like "so you won't use boxes by themselves very often." to contrast to your next sentence.

sophiajt · 2017-02-22T22:10:05Z

src/ch15-00-smart-pointers.md

+The compiler will look at this type, and say "How much memory do I need to
+allocate for a value of `SomeEnum`?  Let's look at `A`. Well, it has a value of
+type `Box<SomeEnum<T>>`, and we know that a box always has the size of a
+`usize`. Then, let's look at `B`. It doesn't save a value, so we don't need any


I know this, but how does the reader know this?

You just said SomeEnum leads to recursion, how does adding one more level of abstraction break the loop? Don't I have to know the size of SomeEnum to know the Box of it? How is Box different?

I mean, you don't have to go into too much detail, but you're asking them to trust you here but I think there are probably a couple sentences mixing that lets them follow you the whole way.

I'm adding this text just before the enum definition that uses Box, I think this will resolve it, please comment if not (and feel free to wait til i push up my changes to see them in context):

Because a Box<T> is a pointer, we always know what size it is: a usize, which is the size of a pointer. The value of the usize will be the address of the heap data. The heap data can be any size, but the address to the start of that heap data will always fit in a usize.

The part you commented on now reads (also changed this example to use List/Cons/Nil):

The Cons variant will need the size of whatever T is, plus the space to store a usize, since a box always has the size of a usize.

thus removing the "we know" part.

sophiajt · 2017-02-22T22:21:13Z

src/ch15-00-smart-pointers.md

+    value: T,
+}
+
+impl<T> Deref for DerefExample<T> {


I like that we go into explaining Deref. It feels like it helps unlock their ability to learn Rust more deeply on their own.

I was wondering if we wanted to show the Deref trait so they know what you're implementing.

We haven't covered associated types at this point yet, so we kind of want to gloss over that.

Also it's basically just this. I'm going to add a sentence before this example that says "the Deref trait requires implementing the deref method that borrows self and returns a reference to whatever part of the data you want returned" or similar.

sophiajt · 2017-02-22T23:06:16Z

src/ch15-00-smart-pointers.md

+
+1. We use `5` in sample one, but `Cell::new(5)` in sample two.
+2. We use `=` in sample one, but `set` in sample two.
+3. `five` is mutable in sample one, but not in sample two.


These three points don't help me understand what interior mutability is or why you would want it. I think the reader can assume that some patterns will be syntactically different. It feels like the first thing the reader will want is "okay what is this interior mutability thing?"

sophiajt · 2017-02-22T23:07:53Z

src/ch15-00-smart-pointers.md

+}
+```
+
+There's a lot going on here. Fundamentally, `Cycle` is a type that contains an


Probably don't need "Fundamentally,"

sophiajt · 2017-02-22T23:08:11Z

src/ch15-00-smart-pointers.md

+```
+
+There's a lot going on here. Fundamentally, `Cycle` is a type that contains an
+`Rc<Cycle>`. This means that we can have a 'referene cycle', hence the name of


s/referene/reference

sophiajt · 2017-02-22T23:11:19Z

src/ch15-00-smart-pointers.md

+
+Now, as you can see, doing this is very hard. To be honest, your authors had to
+look up previous discussions of an example to get this right. But it can
+happen, and the way that it happens is reasonably obvious: If you have an


i reworded and mooted

sophiajt · 2017-02-22T23:12:01Z

src/ch15-00-smart-pointers.md


-Now let's talk about concurrency, and some smart pointers that can be used
-with multiple threads.
+Next, let's talk about concurrency in Rust. We'll even learn aobut a few new


s/aobut/about

matthewjasper

Some thoughts.
Also +1 to most of Jonathan's comments.

matthewjasper · 2017-02-22T22:03:30Z

src/ch15-00-smart-pointers.md

+    A(SomeEnum<T>),
+    B,
+}
+```


What happened to List<T>?

i like you, literally just said the same thing to steve before reading this

matthewjasper · 2017-02-22T22:04:38Z

src/ch15-00-smart-pointers.md

+enum List<T> {
+    Cons(T, List<T>),
+    Nil,
+}


In the following examples, would make things simpler to not use generics?

matthewjasper · 2017-02-22T22:06:31Z

src/ch15-00-smart-pointers.md

+{
+    let y = &mut x;
+
+    *y += 1


This example should probably be a use of Deref, not DerefMut.
Alternatively, it could have one of each and be referred to when DerefMut is mentioned.

Ah, good point. This example doesn't actually exist in chapter 4 currently; we're also going to go back there and add something along these lines and then rework this example so that it's actually referring back to something.

matthewjasper · 2017-02-22T22:18:40Z

src/ch15-00-smart-pointers.md

+parameter.
+
+if you look at the `assert_eq!`, we're comparing `'a'` to `*example`: the `*`
+is what calls `Deref::deref`. And in the implementation, we can see that we


Perhaps it would help to mention that
(a) *example is turned into *Deref::deref(&example).
(b) * on references is built in.

matthewjasper · 2017-02-22T22:20:36Z

src/ch15-00-smart-pointers.md

+string slices! This means that `&String` will automatically coerce to a slice
+of the full string. 
+
+There's also a `DerefMut` trait for overriding `*` on `&mut T`s in the same


Overriding * in assignments. This is where the example at the start of the previous could be used.

matthewjasper · 2017-02-22T23:14:07Z

src/ch15-00-smart-pointers.md

+```
+
+The difference between `Cell<T>` and `RefCell<T>` mirrors the difference
+between types that are `Copy` and types that are not; if we don't need the


The point here is then that with Copy types we can pass around copies to avoid references.

matthewjasper · 2017-02-22T23:18:14Z

src/ch15-00-smart-pointers.md

+call interior mutability a "pattern" is that it's not really a language
+feature, it's a design pattern for libraries. More specifically, it's a pattern
+that uses `unsafe` code inside to bend Rust's usual rules. We haven't yet covered
+unsafe code in-depth, we will in Chapter 20. Luckily for us, you don't have to


I'm not sure if Chapter 20 can hope to cover unsafe code "in-depth".

matthewjasper · 2017-02-22T23:28:30Z

src/ch15-00-smart-pointers.md


-### The Interior Mutability Pattern
+`Weak<T>` is exactly like `Rc<T>`, except that its reference count doesn't, well,
+count when determining if something should be freed. You can turn an `Rc<T>` into


dropped, not freed.

matthewjasper · 2017-02-22T23:28:52Z

src/ch15-00-smart-pointers.md

-### The Interior Mutability Pattern
+`Weak<T>` is exactly like `Rc<T>`, except that its reference count doesn't, well,
+count when determining if something should be freed. You can turn an `Rc<T>` into
+a `Weak<T>` with the `Rc::downgrade` associated method, which takes an `&Rc<T>`


associated function

matthewjasper · 2017-02-22T23:32:04Z

src/ch15-00-smart-pointers.md

+So in this example, when we call `oh_no.clone()`, we increment the count to two.
+But when we pass that clone to `downgrade`, that count goes down again, to one.
+Now, at the end of the function, when `oh_no` goes out of scope, it reduces the
+count from one to zero, and the memory is freed. Success! We've broken the cycle.


Oh, being accurate with drop/free would make this more complicated.

Dropping the T value in the Rc<T> and freeing the underlying memory are separate steps.
That said, I don't think that this matters any more (here).

To say a bit more:
Memory is freed once there are no Rc<T> or Weak<T> pointing to that memory (to keep the reference counts around), so I thought that it's clone that actually frees the memory. But in this case clone is inside the Rc so oh_no frees the memory.

carols10cents · 2017-02-27T01:00:12Z

Ok @steveklabnik @matthewjasper @jonathandturner @parir @gypsydave5, I think this is ready-ish for rereview. There are still a few TODOs, but the main content is done and I'd love your feedback.

The TODOs I have are:

I still need to go back to chapter 4 to put in a bit about deref in general and then update the back references here and here
I'm confused about why we're not allowed to call Drop::drop explicitly, only std::mem::drop, and I'd like some help explaining that here
I want to add some diagrams, probably graphviz things, here and here. Please imagine super awesome diagrams in the meantime.
I might be recommending a Bad Thing™ here in terms of software design-- i've created two separate scenarios that return the same value. It's setting off my internal alarm bells, I'm trying to tell them to shut up because this chapter is complicated enough, I'm wondering if other people think this is good or bad?

steveklabnik · 2017-02-27T02:16:04Z

src/ch15-06-reference-cycles.md

+To create `Weak<T>` values, we call the `Rc::downgrade` associated function,
+which takes an `&Rc<T>` as an argument, and gives a `Weak<T>` back.
+
+Listing 15-16 shows a `main` method where we're trying to create `a` and `b` lists that point to each other, similarly to what we did in Listing 15-14, but this time we won't have a reference cycle and the values will be dropped when they go out of scope at the end of `main`:


needs wrapped

aturon

The interior mutability section looks solid! I left just a few suggestions/clarifications, as well as some notes on other parts of the chapter.

aturon · 2017-03-01T11:10:28Z

src/ch15-00-smart-pointers.md

+sense, `String` and `Vec<T>` from Chapter 8 are both smart pointers. They own
+some memory and allow you to manipulate it, and have metadata (like their
+capacity) and extra capabilities or guarantees (`String` data will always be
+valid UTF-8). Another good example is `File`, which we used for our I/O project


I think File is probably not a good example, if you're treating Deref as crucial (which I think you should).

aturon · 2017-03-01T11:12:21Z

src/ch15-00-smart-pointers.md

+frequently in Rust, this chapter won't cover every smart pointer that exists.
+Many libraries have their own and you may write some yourself. The ones we
+cover here are the most common ones from the standard library: `Box<T>`,
+`Rc<T>`, and `RefCell<T>`. Along the way, we'll also cover:


Note that RefCell itself isn't a smart pointer, but the access to data it provides (Ref and RefMut) is.

Well poop. Uh. Idk what to do about this now.

Like..... should we make RefCell/interior mutability into its own chapter...? Frame RefCell as something that's also useful to use with smart pointers?

Well so RefCell does involve smart pointers -- the Ref and RefMut it gives you when you borrow are smart pointers. I think it's fine to go in this chapter, but the text just needs a little bit more precision.

It's worth talking about Ref and RefMut in more detail anyway, since understanding what happens when you drop them can help you understand how RefCell works (which I think is important for grokking "deep Rust").

Is this book meant to help people understand "deep Rust" though, or is that more for the nomicon....?

Heh, let me try a different argument. I personally find understanding how RefCell works really helpful for getting another perspective on borrow checking, and for seeing how various pieces (like Deref and Drop) come together. Obviously it's your call what makes the most sense here in the book. But at the very least, this section can be fixed up by just saying that when you call borrow what you get back is a smart pointer, Ref, which tracks the borrowing dynamically, and for which drop releases the borrow dynamically.

To be super clear: I think the best definition of a "smart pointer" in Rust is just something that implements Deref. The RefCell type doesn't itself, but it crucially depends on its sibling types Ref and RefMut, which do.

Ok @aturon, in this commit I tried to change the text to be more accurate but not go off into the weeds too much. Wdyt?

@aturon oops and this commit too, forgot to hit save

aturon · 2017-03-01T11:13:42Z

src/ch15-01-box.md

+
+The most straightforward smart pointer is a *box*, whose type is written
+`Box<T>`. Boxes allow you to put a single value on the heap, and the pointer to
+that value lives on the stack. (We talked about the stack vs. the heap in


The pointer to the value doesn't necessarily live on the stack; you can put Box<T> values themselves on the heap.

aturon · 2017-03-01T11:19:13Z

src/ch15-03-drop.md

+
+The other trait that's important to the smart pointer pattern is the `Drop`
+trait. `Drop` lets us run some code when a value is about to go out of scope.
+This is especially useful for smart pointers that manage a resource as opposed


This is another case where you're talking about things like File as smart pointers, which isn't right (they don't implement Deref). You should make clear that Drop is a more general concept, that happens to almost always be used when building a smart pointer.

sooooo do you think the WebSocket example in this section should be changed then? If so, what would be a better example?

Nope! You just need to be more clear that the section is a digression about Drop, which is more general than smart pointers. Alternatively, the material on Drop could be moved into an earlier chapter.

I don't really like either of those options :(

Sorry, let me recommend something more specific. Change:

This is especially useful for smart pointers that manage a resource as opposed to those that manage memory: often resources like files or network connections need to be closed when our code is done with them.

to:

Smart pointers perform important cleanup when being dropped, like deallocating memory or decrementing a reference count. More generally, data types can manage resources beyond memory, like files or network connections, and use Drop to release those resources when our code is done with them.

aturon · 2017-03-01T11:22:54Z

src/ch15-05-interior-mutability.md

@@ -0,0 +1,238 @@
+## `RefCell<T>` and the Interior Mutability Pattern
+
+*Interior mutability* is a design pattern in Rust for allowing you to mutate


This opening sentence is a bit problematic; it's not that you can mutate immutable data, it's that you can mutate data even though it's behind a shared reference, which would normally prevent mutation.

aturon · 2017-03-01T11:24:11Z

src/ch15-05-interior-mutability.md

+*Interior mutability* is a design pattern in Rust for allowing you to mutate
+data that's immutable. The interior mutability pattern involves using `unsafe`
+code inside a data structure to bend Rust's usual rules around mutation and
+borrowing. We haven't yet covered unsafe code, we will in Chapter 20. The


I think it'd be good to add here: the pattern is used when you can somehow ensure that the rules about borrowing will be followed at runtime, even though the compiler can't prove that to itself.

aturon · 2017-03-01T11:27:19Z

src/ch15-05-interior-mutability.md

+
+### `RefCell<T>` has Interior Mutability
+
+Unlike `Rc<T>`, the `RefCell<T>` type represents single ownership over the data


@nikomatsakis, do you have a good explanation for the name Cell?

aturon · 2017-03-01T11:31:02Z

src/ch15-05-interior-mutability.md

+Static analysis, like the Rust compiler performs, is inherently conservative.
+That is, if Rust accepts an incorrect program, people would not be able to
+trust in the guarantees Rust makes. If Rust rejects a correct program, the
+programmer will be inconvenienced, but nothing catastrophic can occur.


Probably want to add: it's not possible for a static analysis to have perfect precision (maybe with a link to the halting problem?) Otherwise it's not clear why it's inherently conservative.

aturon · 2017-03-01T11:31:39Z

src/ch15-05-interior-mutability.md

+
+1. When you know that the borrowing rules are respected, but when the compiler
+  can't understand that that's true.
+2. When you need interior mutability.


I would drop the second of these situations, because it follows from the first.

aturon · 2017-03-01T11:33:17Z

src/ch15-05-interior-mutability.md

+
+Here, we've created a new `RefCell<T>` containing the value 5. We can get an
+immutable reference to the value inside the `RefCell<T>` by calling the `borrow`
+method. More interestingly, we can get a mutable reference to the value inside


It's hard for the reader to see the really key point here: the fact that you can do this with just a & pointer to data. Maybe you can break out the body of main into a function that takes &RefCell<i32> to drive this home.

matthewjasper · 2017-03-01T12:01:34Z

src/ch15-06-reference-cycles.md

+`weak_count` of references to an `Rc`. When an `Rc` goes out of scope, the
+inner value will get dropped if the `strong_count` is 0, even if the
+`weak_count` is not 0. When we attempt to use a `Weak<T>` reference, we'll get
+an `Option<T>` that will be `Some` if the `Rc` value has not been dropped yet,


I think 'attempt to use a Weak' is a bit ambiguous. I think you mean: to be able to use [get the value from] a Weak<T>, it first has to be upgraded to an Option<Rc<T>> [that will be some ...].

matthewjasper · 2017-03-01T12:57:05Z

Some thoughts on the Weak<T> example:

Putting value first in Node<T> would maybe make the Debug output clearer.
Adding some more new lines to the output of the example would help.
Just less printing would also help.
Moving some of the common code into functions would make the example shorter, maybe easier to understand.
Using a struct that has a Drop implementation that prints something might be helpful to show that everything is cleaned up.
This could then allow an exercise like "try replacing Weak<T> with Option<Rc<T>> to see that some things aren't dropped, don't forget to comment out all of the debug printing.".

matthewjasper

These are hopefully my last comments.

matthewjasper · 2017-03-01T22:27:45Z

src/ch15-05-interior-mutability.md

@@ -162,16 +180,20 @@ Well, remember when we said that `Rc<T>` has to store immutable data? Given
 that `RefCell<T>` is immutable, but has interior mutability, we can combine


One last (I think) case of 'immutable data'.

matthewjasper · 2017-03-01T22:28:06Z

src/ch15-03-drop.md

+always used when implementing smart pointers.
+
+In some other languages, we have to remember to call code to free the memory or
+resource every time we finish using an instance of a smart pointer. If we


Is 'smart pointer' the right way refer to things in other languages?

it is in C++, and other similar kinds of languages, yeah

carols10cents · 2017-03-02T16:29:56Z

These are hopefully my last comments.

i hope so too omg i'm so sick of this chapter

I cannot for the life of me get the arrow currently pointing from a -> 10 to point from 10 -> a instead, dir=back has no effect, changing the order makes the whole graph go kablooey, i even tried hand-editing the svg and i cannot

carols10cents · 2017-03-03T15:56:20Z

I'm going to ship this to nostarch and explain that the one diagram isn't quite what we want but we're working on fixing it. I'm expecting to have to rearrange and reword lots of stuff when we get comments from nostarch, so if anyone has any comments/suggestions/feedback between now and then, please open a new issue and we'll take care of it then! Thank you to everyone who helped on this chapter! ❤️

parir reviewed Jan 20, 2017

View reviewed changes

carols10cents reviewed Feb 2, 2017

View reviewed changes

gypsydave5 reviewed Feb 21, 2017

View reviewed changes

steveklabnik added 3 commits February 22, 2017 14:54

Chapter 15: Smart pointers

0d32bbe

more work on smart pointers

4ad2690

finish off draft

ac61cbd

steveklabnik force-pushed the ch15-smart-pointers branch from fdb45a9 to ac61cbd Compare February 22, 2017 19:55

sophiajt reviewed Feb 22, 2017

View reviewed changes

matthewjasper reviewed Feb 22, 2017

View reviewed changes

carols10cents added 9 commits February 23, 2017 13:18

First editing pass

01e407a

Address most comments, make more notes

092ff98

A more thorough editing pass

54e807c

More edits

12e12c8

All but the summary

b07ce30

Whew. Finish editing.

3af06ba

Split into sections

5af5c49

Connect Drop a bit more to Rc

8a39ec9

Multithreaded, one word, is in No Starch's style guide

d2e6325

steveklabnik commented Feb 27, 2017

View reviewed changes

Another attempt at the Weak<T> example

6672fd6

aturon reviewed Mar 1, 2017

View reviewed changes

matthewjasper reviewed Mar 1, 2017

View reviewed changes

carols10cents added 7 commits March 1, 2017 13:20

Set up example about borrowing rules on refcell better

bf02924

Remove unnecessary sentence

b460d00

Fix capitalization

5c6c1ab

Remove File since it doesn't implement Deref

e4658ca

Remove sentence about box being on the stack; not quite true

c981fc0

Address most of aturon's comments

84255f9

Try to make examples a bit clearer

52d109f

matthewjasper reviewed Mar 1, 2017

View reviewed changes

carols10cents added 2 commits March 2, 2017 11:25

Try to clarify that RefCell isn't really a smart pointer

90c380c

More RefCell clarification

72b4ceb

carols10cents added 12 commits March 2, 2017 11:32

Clarify another instance of immutable data

d7ade00

Use a sillier example than the non-functioning WebSocket

6646733

Incorporate the Weak example

90ba6d3

See if we can get away with not editing chapter 4

542013a

Fixing spelling and tests

b13b292

Infinite type illustration

0e27654

Add a diagram for Cons with Box

a17e7ca

Add more figures

07310e5

graphviz is terrible

87609b1

wrong way arrow

5f6113d

halp can't get arrow pointing the way i want

3bfc407

I cannot for the life of me get the arrow currently pointing from a -> 10 to point from 10 -> a instead, dir=back has no effect, changing the order makes the whole graph go kablooey, i even tried hand-editing the svg and i cannot

more diagrams

364ff83

carols10cents merged commit b7f5dc5 into master Mar 3, 2017

carols10cents deleted the ch15-smart-pointers branch March 3, 2017 16:09

		@@ -0,0 +1,238 @@
		## `RefCell<T>` and the Interior Mutability Pattern

		Interior mutability is a design pattern in Rust for allowing you to mutate


		### `RefCell<T>` has Interior Mutability

		Unlike `Rc<T>`, the `RefCell<T>` type represents single ownership over the data

		@@ -162,16 +180,20 @@ Well, remember when we said that `Rc<T>` has to store immutable data? Given
		that `RefCell<T>` is immutable, but has interior mutability, we can combine

Chapter 15: Smart pointers #407

Chapter 15: Smart pointers #407

Uh oh!

Conversation

steveklabnik commented Jan 17, 2017

Uh oh!

parir left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

carols10cents left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

steveklabnik commented Feb 22, 2017

Uh oh!

steveklabnik commented Feb 22, 2017

Uh oh!

sophiajt left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

matthewjasper left a comment