@@ -1067,6 +1067,26 @@ let mut d = @mut 5; // mutable variable, mutable box
1067
1067
d = @mut 15;
1068
1068
~~~~
1069
1069
1070
+ A mutable variable and an immutable variable can refer to the same box, given
1071
+ that their types are compatible. Mutability of a box is a property of its type,
1072
+ however, so for example a mutable handle to an immutable box cannot be
1073
+ assigned a reference to a mutable box.
1074
+
1075
+ ~~~~
1076
+ let a = @1; // immutable box
1077
+ let b = @mut 2; // mutable box
1078
+
1079
+ let mut c : @int; // declare a variable with type managed immutable int
1080
+ let mut d : @mut int; // and one of type managed mutable int
1081
+
1082
+ c = a; // box type is the same, okay
1083
+ d = b; // box type is the same, okay
1084
+
1085
+ // but b cannot be assigned to c, or a to d
1086
+ c = b; // error
1087
+ ~~~~
1088
+
1089
+
1070
1090
# Move semantics
1071
1091
1072
1092
Rust uses a shallow copy for parameter passing, assignment and returning values
@@ -1081,6 +1101,16 @@ let y = x.clone(); // y is a newly allocated box
1081
1101
let z = x; // no new memory allocated, x can no longer be used
1082
1102
~~~~
1083
1103
1104
+ Since in owned boxes mutabilility is a property of the owner, not the
1105
+ box, mutable boxes may become immutable when they are moved, and vice-versa.
1106
+
1107
+ ~~~~
1108
+ let r = ~13;
1109
+ let mut s = r; // box becomes mutable
1110
+ *s += 1;
1111
+ let t = s; // box becomes immutable
1112
+ ~~~~
1113
+
1084
1114
# Borrowed pointers
1085
1115
1086
1116
Rust's borrowed pointers are a general purpose reference type. In contrast with
@@ -1191,7 +1221,7 @@ they are frozen:
1191
1221
let x = @mut 5;
1192
1222
let y = x;
1193
1223
{
1194
- let y = &*y; // the managed box is now frozen
1224
+ let z = &*y; // the managed box is now frozen
1195
1225
// modifying it through x or y will cause a task failure
1196
1226
}
1197
1227
// the box is now unfrozen again
0 commit comments