## Rust types: Recap
-I have discussed my model of Rust types [in a previous post]({{ site.baseurl }}{% post_url 2018-01-31-sharing-for-a-lifetime %}); this may me a good time to read that post as I will be using it as a starting point.
+I have discussed my model of Rust types [in a previous post]({% post_url 2018-01-31-sharing-for-a-lifetime %}); this may me a good time to read that post as I will be using it as a starting point.
The short version is that I view Rust types with private invariants as not having just a single invariant, but different invariants that reflect the different "modes" the type can be in.
@cramertj suggested to use "typestate" as terminology here, and I agree that this makes sense.
You may be wondering why sharing is a separate typestate here; shouldn't that just be read-only access to a `T` that someone else owns?
However, that clearly doesn't work for `&Cell`; to explain types with interior mutability we *need* sharing as a separate state.
I explained this in more detail in the previous post, but as a quick example consider that, if you fully own a `RefCell`, the first field (storing the current count of readers/writers) has no special meaning whatsoever.
-This is witnessed by [`RefCell::get_mut`](https://doc.rust-lang.org/beta/std/cell/struct.RefCell.html#method.get_mut) ignoring that field.
+This is witnessed by [`RefCell::get_mut`](https://doc.rust-lang.org/stable/std/cell/struct.RefCell.html#method.get_mut) ignoring that field.
In fact, it would be sound to add a `RefCell::reset(&mut self)` that just resets this field to `0`.
## Pinning
Crucially, **pinning does not provide immovable types**!
Data is only pinned after a `Pin<T>` pointing to it has been created; it can be moved freely before that happens.
-The [corresponding RFC](https://github.com/rust-lang/rfcs/blob/master/text/2349-pin.md) explains the entirey new API surface in quite some detail: [`Pin`](https://doc.rust-lang.org/nightly/std/mem/struct.Pin.html), [`PinBox`](https://doc.rust-lang.org/nightly/std/boxed/struct.PinBox.html) and the [`Unpin`](https://doc.rust-lang.org/nightly/std/marker/trait.Unpin.html) marker trait.
+The [corresponding RFC](https://github.com/rust-lang/rfcs/blob/master/text/2349-pin.md) explains the entirey new API surface in quite some detail: [`Pin`](https://doc.rust-lang.org/1.27.0/std/mem/struct.Pin.html), [`PinBox`](https://doc.rust-lang.org/1.27.0/std/boxed/struct.PinBox.html) and the [`Unpin`](https://doc.rust-lang.org/1.27.0/std/marker/trait.Unpin.html) marker trait.
I will not repeat that here but only show one example of how to use `Pin` references and exploit their guarantees:
{% highlight rust %}
#![feature(pin, arbitrary_self_types, optin_builtin_traits)]
fn init(mut self: Pin<SelfReferential>) {
let this : &mut SelfReferential = unsafe { Pin::get_mut(&mut self) };
// Set up self_ref to point to this.data.
- this.self_ref = &mut this.data as *const i32;
+ this.self_ref = &this.data as *const i32;
}
- fn read_ref(mut self: Pin<SelfReferential>) -> Option<i32> {
- let this : &mut SelfReferential = unsafe { Pin::get_mut(&mut self) };
+ fn read_ref(self: Pin<SelfReferential>) -> Option<i32> {
+ let this : &SelfReferential = &*self;
// Dereference self_ref if it is non-NULL.
if this.self_ref == ptr::null() {
None
`Pin` lets us give a type to `SelfReferantial` that makes it safe to use.
This is in the best tradition of Rust: We are using an expressive type system to provide safe APIs for operations that only have unsafe APIs in other languages (e.g., iterators that avoid iterator invalidation which plague even memory safe languages like Java).
In the following, I will explain how one can prove that our claim of safe encapsulation actually holds true.
-This is building on the framework that we developed for the [RustBelt paper]({{ site.baseurl }}{% post_url 2017-07-08-rustbelt %}).
+This is building on the framework that we developed for the [RustBelt paper]({% post_url 2017-07-08-rustbelt %}).
## Formal Notation
projects / web.git / blobdiff