Deterministic Destruction

The actual instant when such objects are allocated is hard to predict, because it depends on compiler optimizations. So, let’s consider the conceptual instant of such allocations.

Conceptually, every stack allocation happens when the corresponding expression first appears in code.

All this is not different from most programming languages.

And when does deallocation of a data item happen?

These deallocation rules differentiate Rust from most programming languages. In any language that has temporary objects or stack-allocated objects, the objects of such kinds are deallocated automatically. But heap-allocated object deallocation differs for different languages.

In some languages, like Pascal, C, and C++, heap objects are usually deallocated only explicitly, by invoking functions like “free” or “delete.” In other languages, like Java and C#, heap objects are not immediately deallocated when they are not reachable anymore, but there is a routine, run periodically, which finds unreachable heap objects and deallocates them. This mechanism is named “garbage collection ” because it resembles the urban cleaning system: it periodically cleans the town when some garbage has piled up.

So, in C++ and similar languages, heap deallocation is both deterministic and explicit . It is deterministic, because it happens in well-defined positions of source code; and it is explicit, because it requires that the programmer writes a specific deallocation statement. To be deterministic is good, because it has better performance and it allows the programmer to better control what is going on in the computer. But to be explicit is bad, because if deallocations are performed wrongly, nasty bugs result.

In Java and similar languages, heap deallocation is both nondeterministic and implicit. It is nondeterministic because it happens in unknown instants of execution; and it is implicit because it does not require specific deallocation statements. To be nondeterministic is bad, but to be implicit is good.

Differing from both techniques, in Rust, usually, heap deallocation is both deterministic and implicit, and this is a great advantage of Rust over other languages.

This is possible because of the following mechanism, based on the concept of ownership.

Ownership

In this tiny program, the Box::new call allocates a heap object that is an integer whose value is 3, and the declaration of the _num variable allocates a stack object that is a pointer whose value is the address of that integer object. We say that such pointer owns that integer, because when _num gets out of its block, and so becomes unreachable, the referenced integer object, containing the value 3, is deallocated. Here we have that a reference owns an object.

Here, the _a_ref variable declaration allocates a reference, but that reference owns nothing. Indeed, at the end of the nested block, the _a_ref variable gets out of its block, so the reference is deallocated; however, the referenced object, which is the number having value 3, shouldn’t be immediately deallocated, because it must be printed at the last statement.

To ensure that every object is automatically deallocated when it is referenced no more, Rust has this simple rule: in every instant of execution, every heap object must have exactly one owner: no more, no less. When that owner is deallocated, the object itself is deallocated. If there were several owners, the object could be deallocated several times, and this is a bug usually named double free. If there were no owners, the object could never be deallocated, and this is a bug named memory leak.

Assignment Semantics

The compilation of this code will generate, at the last line, the error: borrow of moved value: `v1`. When the value of v1 is assigned to v2, the variable v1 ceases to exist. Trying to use it, even only to get its length, is disallowed by the compiler.

Let’s see why Rust does not implement share semantics. First, if variables are mutable, such semantics would be somewhat confusing. With share semantics, after an item is changed through a variable, that item appears to be changed also when it is accessed through the other variable. It wouldn’t be intuitive, and possibly it is a source of bugs. Therefore, share semantics would be acceptable only for read-only data.

But there is a bigger problem, regarding deallocation. If share semantics was used, both the header of v1 and the header of v2 would own the single data buffer, so when they are deallocated, the same heap buffer would be deallocated twice, causing memory corruption.

To solve this problem, the languages that use share semantics do not deallocate memory at the end of the block in which such memory is allocated. They resort to garbage collection.

Instead, both copy semantics and move semantics are correct. Indeed, the Rust rule regarding deallocation is that any object must have exactly one owner. When copy semantics is used, the original vector buffer keeps its single owner, which is the vector header referenced by v1; and the newly created vector buffer gets its single owner, which is the vector header referenced by v2. On the other hand, when move semantics is used, the single vector buffer changes owner: before the assignment, its owner is the vector header referenced by v1, and after the assignment, its owner is the vector header referenced by v2. Before the assignment, the v2 header does not exist yet, and after the assignment the v1 header does not exist anymore.

And why does Rust not implement copy semantics?

It will print: 0 3 3.

The first statement of the main function initializes the v1 vector. The second one copies that vector to the v2 vector. The third statement moves the contents of v1 to the v3 vector. The last statement prints the current length of the vectors.

The move C++ standard function copies the value of a vector header to another vector header, like Rust assignments do.

In addition, in C++, the move function empties the source vector (v1). This happens because, in C++, a statement cannot make a variable undefined, so the moved object (v1) must have a valid value.

Therefore, at the end of the program, v2 has a copy of the three items, v3 has just the original three items that were created for v1, and v1 is empty.

This will print 3 3.

This Rust program is similar to the previously shown C++ program.

While in C++ the default semantics is a copy, and it is needed to invoke the move standard function to make a move, in Rust the default semantics is a move, and it is needed to invoke the clone standard function to make a copy. So, the second statement copies the buffer of v1 to v2, and the third statement moves the buffer of v1 to v3.

In addition, while the v1 moved vector in C++ is still accessible, but emptied, in Rust such a variable is not accessible at all anymore. So, the last-but-one statement is not allowed. If it is compiled, it would generate the error: borrow of moved value: `v1`.

Copying vs. Moving Performance

The choice of Rust to favor move semantics is about performance. For an object that owns a heap buffer, like a vector, it is faster to move it than to copy it, because a move of the vector is just a copy of the header; while a copy of the vector requires allocating and initializing a potentially large heap buffer, which eventually will be deallocated. In general, the design choices of Rust are to allow any operation, but to use a more compact notation for the safest and more efficient operations.

In addition, in C++, moved objects are not meant to be used anymore, but, to keep the language backward-compatible with the legacy code base, moved objects are still accessible, and there is the chance that a programmer erroneously uses such objects. In addition, to empty a moved vector has a (small) cost, and when a vector is destructed it should be checked if it is empty, and that also has a (small) cost. Rust has been designed to avoid using moved objects, so there is no chance of erroneously using a moved vector; and the compiler can produce better code because it knows when a vector is moved.

Moving and Destroying Objects

All these concepts apply not only to vectors but also to any object that has a reference to a heap object, like a String or a Box.

It will print: 4 4. Any attempt to access s1 at the end of the program will cause a compilation error.

It will print: 0 4 4, because the moved string s1 has become empty, but it is still accessible.

will print: 12345 12345. Any attempt to access i1 at the end of the program will cause a compilation error.

It will print: 0 1 1 12345 12345. The last statement first checks which unique pointers are null, by casting them to the bool type ; only i1 is null, because it was moved to i3. Then, the values referenced by i2 and i3 are printed.

Compiling any of the previous three programs, the last statement causes the compilation error: use of moved value: `v1`.

In particular, in the last program, the compiler complains that v1 is moved to _v2, even if they are both empty, and so no heap is used. Why? Because the rule of moves is applied by the compiler, so it must be independent of the actual content of an object at runtime. It is because the most important principle of Rust is that it is better to know of possible errors at compile time rather than at runtime. At compile time, in general, the compiler cannot know whether a vector will be empty or not empty when it is involved in an assignment.

Here, the compiler can be sure that such objects won’t contain references to the heap, but still it complains about moves. Why does Rust not use copy semantics for this type that will never have references to the heap?

Here is the rationale for this. The user-defined type S now has no references to memory, but after future maintenance of the software, one reference to the heap may easily be added, as a field of S or as a field of a field of S, and so on. So, if we now implement copy semantics for S, when the program source is changed so that a String or Box or a collection is added to S, directly or indirectly, a lot of errors would be caused by this semantic change. So, as a rule, it’s better to keep move semantics by default.

Need for Copy Semantics

It will print: 123 abc 123. How come there is no moved variable?

Well, the fact is that for primitive numbers, static strings, and references, Rust does not use move semantics. For these data types, Rust uses copy semantics.

Why? We saw previously that if an object can own one or more heap objects, its type should implement move semantics; but if it cannot own any heap memory, it can implement copy semantics just as well. Move semantics is a nuisance for primitive types, and it is improbable that they will ever be changed to own some heap objects. So, for them, copy semantics is safe, efficient, and more convenient.

So, some Rust types implement copy semantics, and others implement move semantics. In particular, copy semantics is used by numbers, Booleans, static strings, arrays, tuples, and references. Instead, move semantics is used, by default, by dynamic strings, boxes, any collection (including vectors), enums, structs, and tuple-structs.

Cloning Objects

With regard to the copying of objects, there is another important distinction to apply, regarding which objects it makes sense to copy.

All the types that implement copy semantics can be copied quite easily, with an assignment; but objects that implement move semantics also can be copied, using the clone standard function. We already saw that a clone function can be applied to dynamic strings, boxes, and vectors. However, for some kinds of types, a clone function shouldn’t be applicable, because no kind of copying is appropriate. Think about a file handle, a GUI window handle, or a mutex handle. If you make some copies of one such handle and then you destroy one of the copies, the underlying resource gets released, and the other copies of the handle will be referencing an inexistent resource.

The types of the first kind of objects can implement copy semantics, and they should, because it is more convenient. Let’s call them copyable objects.

The types of the second kind of objects can implement copy semantics, but they should implement move semantics instead, to avoid the runtime cost of unneeded duplications. Moreover, they should provide a method to explicitly duplicate them. Let’s call them cloneable but noncopyable objects.

The types of the third kind of objects should implement move semantics, too. But they shouldn’t provide a method to explicitly duplicate them, because they own a resource that cannot be duplicated by Rust code, and such resource should have just one owner. Let’s call them noncloneable objects .

Of course, any object that can be automatically copied can also be explicitly copied, so any copyable object is also a cloneable object.

To summarize, some objects are noncloneable (like file handles), and other are cloneables (explicitly). Some cloneable objects are also (implicitly) copyable (like numbers), while others are noncopyable (like collections).

To distinguish among these three categories, the Rust standard library contains two specific traits: Copy and Clone. Any type implementing the Copy trait is copyable; any type implementing the Clone trait is cloneable.

This program will print: 123 123 123 [] [] File, and then some information regarding your current directory, like: { fd: 3, path: "/home/yourname/yourdir", read: true, write: false }. It can be compiled only because the three illegal statements have been commented out.

First, a1 is declared as a primitive number. Such type is copyable, and so it can be both explicitly cloned to b1 and implicitly copied to c1. So, there are three distinct objects having the same value, and we can print them all.

Then, a2 is declared as a collection, and specifically a vector of Booleans. Such type is cloneable but not copyable, so it can be explicitly cloned to b2, but the assignment of b2 to c2 is a move, which leaves b2 as undefined. So, after that assignment, we can print a2 and c2, but trying to compile the statement that prints b2 would generate an error with the message: borrow of moved value: `b2`.

At last, a3 is declared as a resource handle, specifically a file handle. Such type is not cloneable, so trying to compile the statement that clones a3 would generate an error with the message: no method named `clone` found for struct `File` in the current scope. It is allowed to assign a3 to c3, but it is a move; so we can print some debug information about c3, but trying to compile the statement that prints a3 would generate an error with the message: borrow of moved value: `a3`.

Making Types Cloneable or Copyable

As said before, enums, structs, and tuple structs, by default, do not implement either the Copy trait or the Clone trait , so they are noncloneable. Though, you may implement the single Clone trait for each of them, of both the Clone trait and the Copy trait.

Notice that to implement the Clone trait requires defining the clone method, which must return a value whose type must be equal to the type of its argument. The returned value should be equal to the value of its argument, but that is not checked by the compiler.

Notice that an implementation of Copy can be empty; it is enough to declare that Copy is implemented, to activate the copy semantics.

The error message explains why: the trait bound `S: Clone` is not satisfied. The Copy trait can be implemented only if the Clone trait is also implemented.

The error message says: the trait `Copy` may not be implemented for this type, indicating the type Vec<i32>.

The program tries to implement the Copy trait for a struct containing a vector. Rust allows you to implement the Copy trait only for types that contain only copyable objects, because copying an object means to copy all its members. Here, Vec does not implement the Copy trait, so S cannot implement it.

It will print: 13 12.

Here, the S struct is not copyable, but it is cloneable because it implements the Clone trait . Therefore, a duplicate of s1 can be assigned to s2. After that assignment, only s1 is modified, and the print statement shows that they are actually different.