@@ -83,13 +83,13 @@ Rust:
8383``` rust
8484# use std :: boxed :: Box ;
8585{
86- let x = Box :: new (5i );
86+ let x = Box :: new (5 );
8787}
8888```
8989
90- The ` Box::new ` function creates a ` Box<T> ` (specifically ` Box<int > ` in this
90+ The ` Box::new ` function creates a ` Box<T> ` (specifically ` Box<i32 > ` in this
9191case) by allocating a small segment of memory on the heap with enough space to
92- fit an ` int ` . But where in the code is the box deallocated? We said before that
92+ fit an ` i32 ` . But where in the code is the box deallocated? We said before that
9393we must have a deallocation for each allocation. Rust handles this for you. It
9494knows that our handle, ` x ` , is the owning reference to our box. Rust knows that
9595` x ` will go out of scope at the end of the block, and so it inserts a call to
@@ -103,12 +103,12 @@ to a function? Let's look at some code:
103103``` rust
104104# use std :: boxed :: Box ;
105105fn main () {
106- let x = Box :: new (5i );
106+ let x = Box :: new (5 );
107107
108108 add_one (x );
109109}
110110
111- fn add_one (mut num : Box <int >) {
111+ fn add_one (mut num : Box <i32 >) {
112112 * num += 1 ;
113113}
114114```
@@ -119,14 +119,14 @@ code, where we print out the value of `x`:
119119``` {rust,ignore}
120120# use std::boxed::Box;
121121fn main() {
122- let x = Box::new(5i );
122+ let x = Box::new(5 );
123123
124124 add_one(x);
125125
126126 println!("{}", x);
127127}
128128
129- fn add_one(mut num: Box<int >) {
129+ fn add_one(mut num: Box<i32 >) {
130130 *num += 1;
131131}
132132```
@@ -153,14 +153,14 @@ box:
153153``` rust
154154# use std :: boxed :: Box ;
155155fn main () {
156- let x = Box :: new (5i );
156+ let x = Box :: new (5 );
157157
158158 let y = add_one (x );
159159
160160 println! (" {}" , y );
161161}
162162
163- fn add_one (mut num : Box <int >) -> Box <int > {
163+ fn add_one (mut num : Box <i32 >) -> Box <i32 > {
164164 * num += 1 ;
165165
166166 num
@@ -179,7 +179,7 @@ to something another handle owns. It's called *borrowing*, and it's done with
179179Here's the current state of our ` add_one ` function:
180180
181181``` rust
182- fn add_one (mut num : Box <int >) -> Box <int > {
182+ fn add_one (mut num : Box <i32 >) -> Box <i32 > {
183183 * num += 1 ;
184184
185185 num
@@ -199,12 +199,12 @@ period. This is also called *borrowing*. Here's a version of `add_one` which
199199borrows its argument rather than taking ownership:
200200
201201``` rust
202- fn add_one (num : & mut int ) {
202+ fn add_one (num : & mut i32 ) {
203203 * num += 1 ;
204204}
205205```
206206
207- This function borrows an ` int ` from its caller, and then increments it. When
207+ This function borrows an ` i32 ` from its caller, and then increments it. When
208208the function is over, and ` num ` goes out of scope, the borrow is over.
209209
210210# Lifetimes
@@ -225,10 +225,10 @@ To fix this, we have to make sure that step four never happens after step
225225three. The ownership system in Rust does this through a concept called
226226* lifetimes* , which describe the scope that a reference is valid for.
227227
228- Let's look at that function which borrows an ` int ` again:
228+ Let's look at that function which borrows an ` i32 ` again:
229229
230230``` rust
231- fn add_one (num : & int ) -> int {
231+ fn add_one (num : & i32 ) -> i32 {
232232 * num + 1
233233}
234234```
@@ -239,7 +239,7 @@ cover the others later. Without eliding the lifetimes, `add_one` looks like
239239this:
240240
241241``` rust
242- fn add_one <'a >(num : & 'a int ) -> int {
242+ fn add_one <'a >(num : & 'a i32 ) -> i32 {
243243 * num + 1
244244}
245245```
@@ -262,22 +262,22 @@ fn add_two<'a, 'b>(...)
262262Then in our parameter list, we use the lifetimes we've named:
263263
264264``` {rust,ignore}
265- ...(num: &'a int ) -> ...
265+ ...(num: &'a i32 ) -> ...
266266```
267267
268- If you compare ` &int ` to ` &'a int ` , they're the same, it's just that the
269- lifetime ` 'a ` has snuck in between the ` & ` and the ` int ` . We read ` &int ` as "a
270- reference to an int " and ` &'a int ` as "a reference to an int with the lifetime 'a.'"
268+ If you compare ` &i32 ` to ` &'a i32 ` , they're the same, it's just that the
269+ lifetime ` 'a ` has snuck in between the ` & ` and the ` i32 ` . We read ` &i32 ` as "a
270+ reference to an i32 " and ` &'a i32 ` as "a reference to an i32 with the lifetime 'a.'"
271271
272272Why do lifetimes matter? Well, for example, here's some code:
273273
274274``` rust
275275struct Foo <'a > {
276- x : & 'a int ,
276+ x : & 'a i32 ,
277277}
278278
279279fn main () {
280- let y = & 5i ; // this is the same as `let _y = 5; let y = &_y;
280+ let y = & 5 ; // this is the same as `let _y = 5; let y = &_y;
281281 let f = Foo { x : y };
282282
283283 println! (" {}" , f . x);
@@ -288,20 +288,20 @@ As you can see, `struct`s can also have lifetimes. In a similar way to functions
288288
289289``` {rust}
290290struct Foo<'a> {
291- # x: &'a int ,
291+ # x: &'a i32 ,
292292# }
293293```
294294
295295declares a lifetime, and
296296
297297``` rust
298298# struct Foo <'a > {
299- x : & 'a int ,
299+ x : & 'a i32 ,
300300# }
301301```
302302
303303uses it. So why do we need a lifetime here? We need to ensure that any reference
304- to a ` Foo ` cannot outlive the reference to an ` int ` it contains.
304+ to a ` Foo ` cannot outlive the reference to an ` i32 ` it contains.
305305
306306## Thinking in scopes
307307
@@ -310,7 +310,7 @@ valid for. For example:
310310
311311``` rust
312312fn main () {
313- let y = & 5i ; // -+ y goes into scope
313+ let y = & 5 ; // -+ y goes into scope
314314 // |
315315 // stuff // |
316316 // |
@@ -321,11 +321,11 @@ Adding in our `Foo`:
321321
322322``` rust
323323struct Foo <'a > {
324- x : & 'a int ,
324+ x : & 'a i32 ,
325325}
326326
327327fn main () {
328- let y = & 5i ; // -+ y goes into scope
328+ let y = & 5 ; // -+ y goes into scope
329329 let f = Foo { x : y }; // -+ f goes into scope
330330 // stuff // |
331331 // |
@@ -337,14 +337,14 @@ This code won't work:
337337
338338``` {rust,ignore}
339339struct Foo<'a> {
340- x: &'a int ,
340+ x: &'a i32 ,
341341}
342342
343343fn main() {
344344 let x; // -+ x goes into scope
345345 // |
346346 { // |
347- let y = &5i ; // ---+ y goes into scope
347+ let y = &5 ; // ---+ y goes into scope
348348 let f = Foo { x: y }; // ---+ f goes into scope
349349 x = &f.x; // | | error here
350350 } // ---+ f and y go out of scope
@@ -375,12 +375,12 @@ alive: they are baked into the data segment of the final binary. Another
375375example are globals:
376376
377377``` rust
378- static FOO : int = 5i ;
379- let x : & 'static int = & FOO ;
378+ static FOO : i32 = 5 ;
379+ let x : & 'static i32 = & FOO ;
380380```
381381
382- This adds an ` int ` to the data segment of the binary, and FOO is a reference to
383- it.
382+ This adds an ` i32 ` to the data segment of the binary, and ` FOO ` is a reference
383+ to it.
384384
385385# Shared Ownership
386386
@@ -395,7 +395,7 @@ struct Car {
395395}
396396
397397struct Wheel {
398- size: int ,
398+ size: i32 ,
399399 owner: Car,
400400}
401401
@@ -431,7 +431,7 @@ struct Car {
431431}
432432
433433struct Wheel {
434- size : int ,
434+ size : i32 ,
435435 owner : Rc <Car >,
436436}
437437
@@ -504,15 +504,15 @@ what the elided lifetimes are expand to:
504504fn print(s: &str); // elided
505505fn print<'a>(s: &'a str); // expanded
506506
507- fn debug(lvl: uint , s: &str); // elided
508- fn debug<'a>(lvl: uint , s: &'a str); // expanded
507+ fn debug(lvl: u32 , s: &str); // elided
508+ fn debug<'a>(lvl: u32 , s: &'a str); // expanded
509509
510510// In the preceeding example, `lvl` doesn't need a lifetime because it's not a
511511// reference (`&`). Only things relating to references (such as a `struct`
512512// which contains a reference) need lifetimes.
513513
514- fn substr(s: &str, until: uint ) -> &str; // elided
515- fn substr<'a>(s: &'a str, until: uint ) -> &'a str; // expanded
514+ fn substr(s: &str, until: u32 ) -> &str; // elided
515+ fn substr<'a>(s: &'a str, until: u32 ) -> &'a str; // expanded
516516
517517fn get_str() -> &str; // ILLEGAL, no inputs
518518
0 commit comments