Rust Programming Language RustConf 2021, 15 Sep 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: RustConf 2021 - Move Constructors: Is it Possible? by Miguel Young de la Sota

Description

Move Constructors: Is it Possible? by Miguel Young de la Sota

A "self-referential" type is one that holds a reference into itself; async Futures are the most common self-referential types in Rust today. However, they can't be moved without invalidating the reference, so they're pinned on the heap or stack. You can't return them or put them into collections (without Boxing, of course). C++ makes heavy use of safely-moveable self-referential types, via move constructors. Bridging move constructors into Rust is one of the great unsolved problems of C++ FFI. Was an unsolved problem. Using a novel interpretation of the Pin P guarantees, we'll port all C++ constructors, not just move constructors, to Rust, without compromising Rust's move-after-use protections (something C++ lacks). Return-by-move and collections are fully supported in today's stable Rust. Beyond zero-cost C++ FFI, Rust "constructors" can be applied to express novel data structures in pure Rust. No C++ knowledge required!

A

Hi, my name is miguel. Today, I'm going to show how move constructors a technique from c plus plus can be used to express a new class of types and rust. This type of programming has frequently been cited as being incompatible with object model, I'm actually going to show that we can make it work to get there we're going to go on a journey through rust to c-plus plus and then back to rust. Again, this talk is a bit dense. So please make sure to ask questions in the chat.

A

If you get confused, I'm going to assume an intermediate level, an intermediate to advanced level, familiarity with rust. Throughout the talk to understand why we care about move constructors, we need to understand self-referential types. We need to want to create a type that can point into itself, we'll start with a struct that contains a value x and a reference to x which we're going to call putter to x, very creative. uh If we write this code, rust actually complains, because rust requires us to give explicit lifetimes to any reference inside of a struct.

A

Now we don't actually want to add a lifetime to the struct itself. We want a lifetime that is sort of like a self-struct that refers to the lifetime of the struct that contains it. Unfortunately, rust really doesn't have a way of expressing this, so we wind up having to use a raw pointer. The barrel.

A

Checker just doesn't know how to deal with this today, I'm going to be using these little boxes containing fields and addresses in order to describe what pointers are doing at any given time, they'll become very important once we start tracking self pointers into different structs.

A

Now that we're using raw pointers, we can make cycle self referential after constructing it, on the stack by you know, put setting assigning protox to the reference to a reference to cycle.x. This creates a little cycle inside of the this, creates a little cycle inside of the inside of the uh pointer, so pay close attention to these arrows because they're going to change over time as we do different things with the struct, we can implement a get function that uses the self pointer to access the other field.

A

Although a little bit contrived, this is a real thing in certain data structures. Being able to create self pointers is very useful for some classes of optimization and is pretty common in. You know performance sensitive code in order to get get to work, we need to maintain an invariant in cycle. Part of x must always be null such as around initialization or a pointer into itself and no other cycle. In other words, these are the only two shapes for a cycle that are allowed.

A

In particular, we cannot have a cycle that points into another. This is not allowed and actually breaks assumptions that we want to make about this type.

A

Now, it's pretty natural to want to factor out this initialization code into a constructor function. The only change from the previous code is that we've copied the let mote cycle part into a function and then call up called that function instead of using the cycle that we initialized previously.

A

But if we do rust will move cycle as it returns out of cycle new when we return by value rest is a move which changes the address of the returned value, but because putter de x is unchanged, it points into cycle new stack, it no longer points to x. Not only does this violate our invariant, but it makes get violate memory safety, because reading data from destroyed stack frame is not allowed.

A

This is pretty bad, so it means that we can't write cycle new this way, while maintaining the other properties we want, because rust moves are implemented as bitewise copies cycle doesn't get a chance to fix up its invariant. This is a general problem with self-referential types, their invariants break. If rust, moves them and rust really likes to silently move things. Halibut rust does provide a good way to avoid this pitfall.

A

Pinned pointers, pin p wraps up a pointer type so that unsafe code like our get function, can assume it never moves. Moreover, it stops safe code from accidentally moving its point d safe code can still do whatever it wants without hurting unsafe assumptions in general. This means that you can't get a mutable reference into the thing behind the behind the pin pointer.

A

You can only get immutable references because you can't swap or replace out of those most rest types are unpin, meaning that they nonetheless can get moved out of a pin like you can unpin an integer because integers don't really know about their address, but a self-referential type like cycle is sensitive to its address and therefore can't be unpin. We, you actually usually disable unpin by adding a special type that I'll show later, most importantly, pin isn't magic, it's a library type and it doesn't really change rust's core semantics.

A

You can still move things around as long as you have them by value. This is unlike types like slices and raw pointers which introduce entire new entirely new language semantics. This will be important later because we will add additional uh additional library guarantees that don't change rust semantics at all.

A

So let's go back to our dangerous implementation of cycle new, because, due to this move, it immediately invalidates the raw pointer we create if we use pin we avoid this entirely by returning a pinned box. You know we, the we ensure that we can't move out of it in any at any time, certainly doesn't move when we return out of it.

A

We also need to make sure that it's pinned the phantom pen type is a zero size, type that just disables unpin every every type that cares about its address needs to include this type as a field. We can now write our code as before. Without any issues, cycle.get will not dereference a dangling pointer note that we can't pull out of it like we could with a normal box.

A

This ensures that safe code can't do anything. Rude, pin lets us write, unsafe code. That requires certain values, never move. There are a number of reasons you might want to do this. This comes up most commonly when writing asynchronous code in rust, but there are other situations in which it's useful, for you know advanced data structures. It also enforces this in safe code.

A

This means that safe code can't accidentally move stuff or do things that unsafe code doesn't doesn't expect so unsafe code can do whatever it wants and safe code can do whatever it wants and unsafe code doesn't need to care.

A

If you're watching closely, though I actually needed to add a box to cycle new to allow me to return the pin to data. This is a problem. We need a pin, we need a pointer to pin in the first place, you can't pin an object and return it that doesn't mean anything in the in the pin formalism.

A

This leads to two major problems with pin number one, because stack stack, allocated, stack, pin data is going to be behind a mutable reference. You can't return it it's the same as with any reference. Therefore, you need to pay the cost of an allocation and box it. We also can't pin data in collections. This is because, basically, every collection that can resize is going to move things when resizing when you, when a vec fills up it, copies everything and treats it as a move.

A

When a hash map hits its its cap, its capacity, it needs to do the same thing. Address sensitive types, don't really fit into the language and using them widely is not free. Okay. So that's enough about languages that suck. Let's talk about c, plus plus, and no. This is not a c plus talk. I don't assume people have encountered it before and I'm going to be very light on the weird c plus syntax you can mostly, you can mostly treat it as rust, with a weird different syntax and no borrow checker.

A

Let's recall our cycle invariant. First, remember that when we have a cycle we want it to be null or a self-reference. We cannot have this version where it points to something else: let's implement cyclone c, plus plus. First, let's define fields like we did in rust.

A

Next, we're going to need to be able to construct it and c plus, plus you use constructors to create values.

A

Unlike a rust, constructor function that might be named new c plus plus constructors get access to this, which is the c plus plus equivalent of self. It is, as if cycle new, somehow took a self parameter. We can take the address of this in the constructor, which we could not do in rust when we call the constructor it silently passes the destination of the new object as the this pointer.

A

So you know, as you can see, a the version in the constructor which didn't really know the concrete address gets a concrete address when actually constructed to make this work c, plus plus allocates space before calling the constructor. So this a lock by array, is just random untyped data. We then use the special new syntax, which is kind of like a raw constructor to tell it hey. Please run this constructor with this explicit this pointer.

A

Finally, we cast it to the correct type, and it's just that business as usual as before, you can call functions on cycle and it's perfectly normal value. In c, plus, all values get constructed in place that is, space is allocated before the constructor runs. As a result, c, plus plus values are always implicitly pinned, they always know their address. They're all address sensitive unless you say otherwise.

A

So what would this raw constructor operator look like in rust? On the left side, I have distributed the c plus plus constructors, from before on the right side. I have a transliteration of that into rust. The raw constructor will be some kind of function, call that accepts uninitialized data and constructs an object there, which is the same signature as the rock constructor.

A

Although the rock instructor does take an additional argument and we'll see how that mixes in later, naturally, we want to capture this function. Signature into a trait new new is a constructor object that can create values of a specific type, but remember that we want to leverage the fact that constructors create pinned values. So we need to make sure to mark the rust version of this as pinned to implement a value to implement a constructor. We create a new type. New cycle is a constructor for cycle.

A

It takes an integer argument and sets up the invariant like the c plus constructor. The difference between this and c plus constructors is that the additional type captures the constructor arguments so, instead of taking an integer, the new new takes itself and self contains that integer argument for other constructors. You might have more or less arguments note that it is not cycle that implements new, because there are many ways to construct a value.

A

For example, you could imagine a default cycle type that takes no arguments notice that the va the body of the rust constructor is almost word for word, identical to the c plus plus version nu lets us capture the destination, address and store it. Just like c plus. We can now set up the cycle invariant without transiting through the null state again just like in c plus, plus it's almost as if we've ported the feature, all all bugs and all the new trait represents constructor objects.

A

You can build a constructor with some parameters and then run it on some storage somewhere. New colon new is rust's equivalent of the raw constructor syntax and is intended to be wrapped in a more ergonomic api. Much like how you usually don't need to call it in c plus, and you can use the syntax sugar of declaring a variable instead, even though we can now create cycles without an intermediate null cycle, we still actually solve the either of the problems we had now. That cycle is pinned on construction.

A

We can't return them at all, maybe that's better or maybe there's an abstraction, we're missing when a function returns. It needs a place to put the the return value, and this is some place in memory called. The return slot c, plus plus contr constructors, actually get special treatment in the c plus plus version of this.

A

When you return a c plus constructor it it's not as though you're assigning it to a variable and returning it. What actually happens is it constructs it in place in the return slot? This means that this code, which wouldn't work at all in rust, works perfectly in c, plus, plus and dodges. The move on return hazard, c plus plus implements this by adding a hidden out parameter to every function. The return slot the this pointer used for the constructor is the return slot.

A

Unlike a local variable like it would be in rust, or at least that's sort of how rust behaves that said, rust does have a return slot and it does use it a little bit in the c plus way, but it's not in a way that is accessible to users and certainly not in a way that we can use it to run a constructor.

A

So what if we just ignore the rust return slot and build our own? Wouldn't that be better that way we can control how things get placed into it. Let's represent the return slot with you know, sort of reference type that is data somewhere, it's uninitialized, we own it and we're responsible for initializing it.

A

It doesn't really matter where it is, but usually it'll, be on a caller on a caller stack slots are the ideal location for running a constructor, their raw memory. Waiting for a value to appear. We can define a method that accepts a constructor, runs it and returns a reference to the result. Consuming the slot so in place takes a slot from the uninitialized state, uses a constructor and then takes the initialized state that the constructor results in.

A

We can then fake a return slot by passing in a slot argument. Instead of returning by value, we run a constructor in the slot and return the resulting reference. This is actually very similar to the c plus plus arrangement under the hood and while still leveraging the borrow checker, both the slot and the pin seem to share the same lifetime. So you don't have any of the concerns you would have in c plus, where the slot might not outlive the result.

A

Okay, so constructors plus slots actually gets the first of these, we can genuinely return objects on the stack, even if it's not quite as ergonomic as it is for unpin types progress. We still can't do. The collections version of this, but c plus plus, seems to make it work, even though all the pointers are pinned. So how do they do it?

A

Let's look at our our c plus cycle type again when we assign a variable to another c plus actually makes a copy. Rather than a move like in rust, much like clone by default, this is a bitewise copy, which means we can run into the same problem where the self pointer invariant is broken. Oops in particular, remember the bitewise copy means the pointer does not get updated, but like rust, we can actually customize this copying behavior.

A

The key difference is that well clone and rust, simply returns by value c, plus, plus copies are done with a constructor. This gives us a chance to fix up the pointer to the no lock new location before it's available for potential misuse. So the cons, the copy constructor, looks almost identical to the normal constructor. It fixes it sets up the invariant and copies the data copies x, but not the pointer c, plus plus variables. Don't move around like in rust. You always construct new ones. Whenever you give a variable a new name.

A

However, objects are always notified of. When this happens, so you can fix up any invariants. The biteways copy would otherwise break. This is similar to clone, but it has all of the pro all of the power of constructors.

A

Obviously, we need to port this to rust, because it's really cool again, let's write down the c plus code and see how we might write it on in rust. On the left side, we have a copy on the right side. We have the the rust constructors exploded out into the version that manually calls the rock constructor operation, unlike constructors, there's only one copy constructor for each type, so it makes sense to give it a specific trait which we're going to call clone new. We don't need to add an additional type that represents the cloning operation.

A

It's like intrinsic to the type being copied the clone neutrate looks almost exactly like clone, except that, instead of returning by value it takes a destination parameter. Just like a constructor would implementing. It is super easy, like we already know how to implement it in c plus, plus we implement it exactly the same way in rust. It's the same with the other constructor.

A

Now we implement this on clone because, as I mentioned before, being copy constructable is a property of the type, rather than them being very many distinct methods for doing so. In c plus, you only really get one copy constructor, so it doesn't really make sense to try to generalize and rust.

A

The new tray is a fusion of clone and new. It's the cloning constructor, but in rust we really like to avoid having to make copies because room semantics are awesome. So how can we recover them?

A

Let's recall back to our move slot abstraction when we create a value in a slot, because the slot is a unique reference to some memory somewhere we're actually the sole owners. No one else will ever access the value. Even after the slot disappears.

A

We can introduce a new type moveref, which is like a mutable reference that captures this ownership property. Not all immutable references can be move refs because some of those might be outlived by other mutable references or other types that are entitled to run. The destructor moveref has to be entitled to run the destructor. That's what ownership means we can use moveref instead of mutable references for the return value of in place. Since it produces a brand new value, no one else will ever access.

A

The key point is that moveref owns its pointee and not its storage. This means that we can move out of it like box, but it's storage agnostic like a mutable reference. You can have move reps that point to the stack or the heap.

A

Now, let's recall copy constructors they're like a constructor, but instead of accepting some special constructor type, they accept a reference to self and write a copy of this. Like supplied destination, we can define move constructors analogously by replacing the source with a pinned, move, ref pin, pinned because that's what in place means, unlike clone new move, new consumes the source and that's why it takes a move ref.

A

However, the implementation is almost identical and it reveals the true nature of custom moves, they're, just copies that consume the source. However, they can also mutate the source to disable its constructor or you know, properly move an owned resource. This is exactly what rust, smooth semantics do for vanilla types that is unpin types, clone new and move new are just the usual clones and moves there's nothing special about them, and it shows that this concept actually reduces to something. We've already encountered in rust, move constructable types. Let us move the immovable.

A

Despite being pinned, we can move data from one location to the other. This doesn't violate the pinning invariance because we control exactly how the value is moved in a way that unsafe code can be made aware of the trait is generic, so we can build custom collections that leverage it instead of doing a wise copy to resize a vector, we can call the move constructor on each and every element as we're resizing it.

A

This is how c, plus plus collections, for example, resize when the contained value is not trivially, copyable, pin data and collection, so long as it can be move constructed is totally something we can do so yeah. We can actually do these things we can make. We can make address sensitive types feel as flexible as normal rest types. We can return them, we can put them in collections.

A

We can really allocate them wherever we want and we can specify complex moving strategies that the normal rust object model would not let us that said. We need to muck around with uninitialized data in order to use any of this, and the ergonomics are really bad. Most people are not going to be writing on safecode they're going to be using these types and the unsafe code under the hood, but it would be best that they don't have to do any of that manually.

A

So in placing a constructor actually only really cares about the constructor value you use everything around, it is boilerplate that can be inferred, however, recall returning painted data is impossible, so we can't use a function to do this, but we can use macros to work around it.

A

For example, the slot macro could be used to allocate some space on the stack and then immediately stick it into a slot so that it can only be accessed through the slot.

A

Unfortunately, the slot macro can't even be an expression, since it needs to allocate on the stack we can use in place in order. We can use the in place operation defined on slots previously to construct values.

A

Unlike the example above this produces a move ref, we can add convenience functions to slot that make it easy to call the clone and move constructors as well. So now we don't need to deal with any unsafe code in order to call constructors. We can just call this macro, allocate some space and then put it in put it directly inside them. This is this is a common enough pattern that we can add a macro to do this even more concisely. The choice of syntax isn't really important.

A

Ultimately, we can make constructors feel simpler and easier to use you can. We could also potentially add functions that let us and place macros into boxes into arcs and other similar similar things that you would want to do the regular value. Really it's a matter of what what conveniences you want to add. Although constructors are implemented purely as a library, we can use macros to add custom syntax to use them safely.

A

Ultimately, what they look like is up to the constructor library. This only scratches the surface of how macros can make constructors feel more natural and part of the language. There is still a lot to do in this time. In this topic, I already implemented the core traits in a crate check out, move it on crates.I o. I want to actually build a move. Respecting veckenhash map, like I described earlier c, plus, has already implemented such things.

A

So it's just a matter of porting the analogous thing from a c plus standard library, I'm most of the way there with back with vec. I don't know to what degree I want to attempt hashmap until someone really moves it and really needs it, because hash maps are pretty complicated.

A

This concept is also very useful for mixed rust c plus code, but I think it can also be useful for certain kinds of pure rust as well I'd like to make examples of both more readily available to motivate this kind of api more in the process of developing this, I sort of realized that pins doc docs, don't express all of the things you can do with it. It only expresses a certain subset of it, I'd like to improve the documents so that they more clearly state the guarantees than what they mean for api design.

A

I have a working version that I'm hoping to propose to the to the rust standard library at some point. Finally, there are tons of c plus features that can make working with constructors easier, such as syntax sugar, from being able to have struct literals, uh using using constructor operations as an expression rather than as a binding.

A

There is a very long list of these things that I'd like to that I'd like to port someday in order to make uh constructors easier to use now, none of this would have been possible without the help of many people who have discussed, who I've discussed this feature with who who gate, who suggested ways to make it more concise, who pointed out flaws in the original design. However, I want to especially thank tyler mandari after he corrected something I assured about pin.

A

I realized that the pin guarantees could be used to express constructors I'd also like to thank manish gorgokar, who encouraged me to publish this idea widely for the benefit of both rust c plus plus interop, and the development of rust in general. Thanks for listening- and I hope you enjoyed my talk.

A