Add comment that field projectin also works with mutable fields

diff --git a/src/libcore/pin.rs b/src/libcore/pin.rs
index ad3e2686228c8794a0d0559a70ffb5462936c367..e1fe0044cc480c4ccfe5da947e577cfb0e89cd81 100644 (file)
--- a/src/libcore/pin.rs
+++ b/src/libcore/pin.rs
@@ -171,11 +171,12 @@
 //!
 //! # Projections and Structural Pinning
 //!
-//! One interesting question arises when considering the interaction of pinning and
-//! the fields of a struct. When can a struct have a "pinning projection", i.e.,
-//! an operation with type `fn(Pin<&Struct>) -> Pin<&Field>`?
-//! In a similar vein, when can a generic wrapper type (such as `Vec<T>`, `Box<T>`, or `RefCell<T>`)
-//! have an operation with type `fn(Pin<&Wrapper<T>>) -> Pin<&T>`?
+//! One interesting question arises when considering the interaction of pinning
+//! and the fields of a struct. When can a struct have a "pinning projection",
+//! i.e., an operation with type `fn(Pin<&Struct>) -> Pin<&Field>`?  In a
+//! similar vein, when can a generic wrapper type (such as `Vec<T>`, `Box<T>`,
+//! or `RefCell<T>`) have an operation with type `fn(Pin<&Wrapper<T>>) ->
+//! Pin<&T>` (or similarly `fn(Pin<&mut Wrapper<T>>) -> Pin<&mut T>`)?
 //!
 //! Having a pinning projection for some field means that pinning is "structural":
 //! when the wrapper is pinned, the field must be considered pinned, too.