@@ -42,14 +42,14 @@ point, but allocated in a different place:
4242~~~
4343# struct Point {x: float, y: float}
4444let on_the_stack : Point = Point {x: 3.0, y: 4.0};
45- let managed_box : @Point = @Point {x: 5.0, y: 1.0};
46- let owned_box : ~Point = ~Point {x: 7.0, y: 9.0};
45+ let shared_box : @Point = @Point {x: 5.0, y: 1.0};
46+ let unique_box : ~Point = ~Point {x: 7.0, y: 9.0};
4747~~~
4848
4949Suppose we wanted to write a procedure that computed the distance between any
5050two points, no matter where they were stored. For example, we might like to
51- compute the distance between ` on_the_stack ` and ` managed_box ` , or between
52- ` managed_box ` and ` owned_box ` . One option is to define a function that takes
51+ compute the distance between ` on_the_stack ` and ` shared_box ` , or between
52+ ` shared_box ` and ` unique_box ` . One option is to define a function that takes
5353two arguments of type ` Point ` —that is, it takes the points by value. But if we
5454define it this way, calling the function will cause the points to be
5555copied. For points, this is probably not so bad, but often copies are
@@ -73,11 +73,11 @@ Now we can call `compute_distance()` in various ways:
7373~~~
7474# struct Point {x: float, y: float}
7575# let on_the_stack : Point = Point{x: 3.0, y: 4.0};
76- # let managed_box : @Point = @Point{x: 5.0, y: 1.0};
77- # let owned_box : ~Point = ~Point{x: 7.0, y: 9.0};
76+ # let shared_box : @Point = @Point{x: 5.0, y: 1.0};
77+ # let unique_box : ~Point = ~Point{x: 7.0, y: 9.0};
7878# fn compute_distance(p1: &Point, p2: &Point) -> float { 0f }
79- compute_distance(&on_the_stack, managed_box );
80- compute_distance(managed_box, owned_box );
79+ compute_distance(&on_the_stack, shared_box );
80+ compute_distance(shared_box, unique_box );
8181~~~
8282
8383Here, the ` & ` operator takes the address of the variable
@@ -87,11 +87,11 @@ value. We also call this _borrowing_ the local variable
8787` on_the_stack ` , because we have created an alias: that is, another
8888name for the same data.
8989
90- In contrast, we can pass the boxes ` managed_box ` and ` owned_box ` to
90+ In contrast, we can pass the boxes ` shared_box ` and ` unique_box ` to
9191` compute_distance ` directly. The compiler automatically converts a box like
9292` @Point ` or ` ~Point ` to a borrowed pointer like ` &Point ` . This is another form
93- of borrowing: in this case, the caller lends the contents of the managed or
94- owned box to the callee.
93+ of borrowing: in this case, the caller lends the contents of the shared or
94+ unique box to the callee.
9595
9696Whenever a caller lends data to a callee, there are some limitations on what
9797the caller can do with the original. For example, if the contents of a
@@ -155,7 +155,7 @@ let rect_stack = &Rectangle {origin: Point {x: 1f, y: 2f},
155155 size: Size {w: 3f, h: 4f}};
156156let rect_managed = @Rectangle {origin: Point {x: 3f, y: 4f},
157157 size: Size {w: 3f, h: 4f}};
158- let rect_owned = ~Rectangle {origin: Point {x: 5f, y: 6f},
158+ let rect_unique = ~Rectangle {origin: Point {x: 5f, y: 6f},
159159 size: Size {w: 3f, h: 4f}};
160160~~~
161161
@@ -168,7 +168,7 @@ operator. For example, I could write:
168168# struct Rectangle {origin: Point, size: Size}
169169# let rect_stack = &Rectangle {origin: Point {x: 1f, y: 2f}, size: Size {w: 3f, h: 4f}};
170170# let rect_managed = @Rectangle {origin: Point {x: 3f, y: 4f}, size: Size {w: 3f, h: 4f}};
171- # let rect_owned = ~Rectangle {origin: Point {x: 5f, y: 6f}, size: Size {w: 3f, h: 4f}};
171+ # let rect_unique = ~Rectangle {origin: Point {x: 5f, y: 6f}, size: Size {w: 3f, h: 4f}};
172172# fn compute_distance(p1: &Point, p2: &Point) -> float { 0f }
173173compute_distance(&rect_stack.origin, &rect_managed.origin);
174174~~~
@@ -179,7 +179,7 @@ as well as from the managed box, and then compute the distance between them.
179179# Borrowing managed boxes and rooting
180180
181181We’ve seen a few examples so far of borrowing heap boxes, both managed
182- and owned . Up till this point, we’ve glossed over issues of
182+ and unique . Up till this point, we’ve glossed over issues of
183183safety. As stated in the introduction, at runtime a borrowed pointer
184184is simply a pointer, nothing more. Therefore, avoiding C's problems
185185with dangling pointers requires a compile-time safety check.
@@ -258,18 +258,18 @@ fn example2() {
258258Now if ` x ` is reassigned, the pointer ` y ` will still remain valid. This
259259process is called * rooting* .
260260
261- # Borrowing owned boxes
261+ # Borrowing unique boxes
262262
263263The previous example demonstrated * rooting* , the process by which the
264264compiler ensures that managed boxes remain live for the duration of a
265- borrow. Unfortunately, rooting does not work for borrows of owned
266- boxes, because it is not possible to have two references to a owned
265+ borrow. Unfortunately, rooting does not work for borrows of unique
266+ boxes, because it is not possible to have two references to a unique
267267box.
268268
269- For owned boxes, therefore, the compiler will only allow a borrow * if
270- the compiler can guarantee that the owned box will not be reassigned
269+ For unique boxes, therefore, the compiler will only allow a borrow * if
270+ the compiler can guarantee that the unique box will not be reassigned
271271or moved for the lifetime of the pointer* . This does not necessarily
272- mean that the owned box is stored in immutable memory. For example,
272+ mean that the unique box is stored in immutable memory. For example,
273273the following function is legal:
274274
275275~~~
@@ -294,7 +294,7 @@ and `x` is declared as mutable. However, the compiler can prove that
294294and in fact is mutated later in the function.
295295
296296It may not be clear why we are so concerned about mutating a borrowed
297- variable. The reason is that the runtime system frees any owned box
297+ variable. The reason is that the runtime system frees any unique box
298298_ as soon as its owning reference changes or goes out of
299299scope_ . Therefore, a program like this is illegal (and would be
300300rejected by the compiler):
@@ -342,7 +342,7 @@ which has been freed.
342342
343343In fact, the compiler can apply the same kind of reasoning to any
344344memory that is _ (uniquely) owned by the stack frame_ . So we could
345- modify the previous example to introduce additional owned pointers
345+ modify the previous example to introduce additional unique pointers
346346and structs, and the compiler will still be able to detect possible
347347mutations:
348348
@@ -366,7 +366,7 @@ invalidate the pointer `y`.
366366# Borrowing and enums
367367
368368The previous example showed that the type system forbids any borrowing
369- of owned boxes found in aliasable, mutable memory. This restriction
369+ of unique boxes found in aliasable, mutable memory. This restriction
370370prevents pointers from pointing into freed memory. There is one other
371371case where the compiler must be very careful to ensure that pointers
372372remain valid: pointers into the interior of an ` enum ` .
@@ -462,14 +462,14 @@ of a `float` as if it were a struct with two fields would be a memory
462462safety violation.
463463
464464So, in fact, for every ` ref ` binding, the compiler will impose the
465- same rules as the ones we saw for borrowing the interior of a owned
465+ same rules as the ones we saw for borrowing the interior of a unique
466466box: it must be able to guarantee that the ` enum ` will not be
467467overwritten for the duration of the borrow. In fact, the compiler
468468would accept the example we gave earlier. The example is safe because
469469the shape pointer has type ` &Shape ` , which means "borrowed pointer to
470470immutable memory containing a ` shape ` ". If, however, the type of that
471471pointer were ` &mut Shape ` , then the ref binding would be ill-typed.
472- Just as with owned boxes, the compiler will permit ` ref ` bindings
472+ Just as with unique boxes, the compiler will permit ` ref ` bindings
473473into data owned by the stack frame even if the data are mutable,
474474but otherwise it requires that the data reside in immutable memory.
475475
@@ -550,7 +550,7 @@ guarantees; in fact, it cannot guarantee that the pointer will remain
550550valid at all once it returns, as the parameter ` p ` may or may not be
551551live in the caller. Therefore, the compiler will report an error here.
552552
553- In general, if you borrow a managed (or owned ) box to create a
553+ In general, if you borrow a managed (or unique ) box to create a
554554borrowed pointer, the pointer will only be valid within the function
555555and cannot be returned. This is why the typical way to return borrowed
556556pointers is to take borrowed pointers as input (the only other case in
0 commit comments