@@ -91,7 +91,7 @@ fn read_int_pairs() -> ~[(int,int)] {
91
91
[a, b] => {
92
92
93
93
// 5. Try parsing both fields as ints.
94
- match (from_str::<int> (a), from_str::<int> (b)) {
94
+ match (int::from_str (a), int::from_str (b)) {
95
95
96
96
// 6. If parsing succeeded for both, push both.
97
97
(Some(a), Some(b)) => pairs.push((a,b)),
@@ -124,7 +124,7 @@ for conveying a value of type `T`, represented as `Some(T)`
124
124
_ or_ the sentinel ` None ` , to indicate the absence of a ` T ` value.
125
125
For simple APIs, it may be sufficient to encode errors as ` Option<T> ` ,
126
126
returning ` Some(T) ` on success and ` None ` on error.
127
- In the example program, the call to ` from_str::<int> ` returns ` Option<int> `
127
+ In the example program, the call to ` int::from_str ` returns ` Option<int> `
128
128
with the understanding that "all parse errors" result in ` None ` .
129
129
The resulting ` Option<int> ` values are matched against the pattern ` (Some(a), Some(b)) `
130
130
in steps 5 and 6 in the example program,
@@ -161,7 +161,7 @@ This second mechanism for indicating an error is called a `Result`.
161
161
The type ` std::result::Result<T,E> ` is another simple ` enum ` type with two forms, ` Ok(T) ` and ` Err(E) ` .
162
162
The ` Result ` type is not substantially different from the ` Option ` type in terms of its ergonomics.
163
163
Its main advantage is that the error constructor ` Err(E) ` can convey _ more detail_ about the error.
164
- For example, the ` from_str ` API could be reformed
164
+ For example, the ` int:: from_str` API could be reformed
165
165
to return a ` Result ` carrying an informative description of a parse error,
166
166
like this:
167
167
@@ -172,7 +172,7 @@ enum IntParseErr {
172
172
BadChar(char)
173
173
}
174
174
175
- fn from_str(&str) -> Result<int,IntParseErr> {
175
+ fn int:: from_str(&str) -> Result<int,IntParseErr> {
176
176
// ...
177
177
}
178
178
~~~~
@@ -297,8 +297,8 @@ fn read_int_pairs() -> ~[(int,int)] {
297
297
let line = fi.read_line();
298
298
let fields = line.word_iter().to_owned_vec();
299
299
match fields {
300
- [a, b] => pairs.push((from_str::<int> (a).unwrap(),
301
- from_str::<int> (b).unwrap())),
300
+ [a, b] => pairs.push((int::from_str (a).unwrap(),
301
+ int::from_str (b).unwrap())),
302
302
303
303
// Explicitly fail on malformed lines.
304
304
_ => fail!()
@@ -398,8 +398,8 @@ fn read_int_pairs() -> ~[(int,int)] {
398
398
let line = fi.read_line();
399
399
let fields = line.word_iter().to_owned_vec();
400
400
match fields {
401
- [a, b] => pairs.push((from_str::<int> (a).unwrap(),
402
- from_str::<int> (b).unwrap())),
401
+ [a, b] => pairs.push((int::from_str (a).unwrap(),
402
+ int::from_str (b).unwrap())),
403
403
404
404
// On malformed lines, call the condition handler and
405
405
// push whatever the condition handler returns.
@@ -475,8 +475,8 @@ fn read_int_pairs() -> ~[(int,int)] {
475
475
let line = fi.read_line();
476
476
let fields = line.word_iter().to_owned_vec();
477
477
match fields {
478
- [a, b] => pairs.push((from_str::<int> (a).unwrap(),
479
- from_str::<int> (b).unwrap())),
478
+ [a, b] => pairs.push((int::from_str (a).unwrap(),
479
+ int::from_str (b).unwrap())),
480
480
_ => pairs.push(malformed_line::cond.raise(line.clone()))
481
481
}
482
482
}
@@ -553,8 +553,8 @@ fn read_int_pairs() -> ~[(int,int)] {
553
553
let line = fi.read_line();
554
554
let fields = line.word_iter().to_owned_vec();
555
555
match fields {
556
- [a, b] => pairs.push((from_str::<int> (a).unwrap(),
557
- from_str::<int> (b).unwrap())),
556
+ [a, b] => pairs.push((int::from_str (a).unwrap(),
557
+ int::from_str (b).unwrap())),
558
558
559
559
// On malformed lines, call the condition handler and
560
560
// either ignore the line (if the handler returns `None`)
@@ -649,8 +649,8 @@ fn read_int_pairs() -> ~[(int,int)] {
649
649
let line = fi.read_line();
650
650
let fields = line.word_iter().to_owned_vec();
651
651
match fields {
652
- [a, b] => pairs.push((from_str::<int> (a).unwrap(),
653
- from_str::<int> (b).unwrap())),
652
+ [a, b] => pairs.push((int::from_str (a).unwrap(),
653
+ int::from_str (b).unwrap())),
654
654
655
655
// On malformed lines, call the condition handler and
656
656
// take action appropriate to the enum value returned.
@@ -776,7 +776,7 @@ fn main() {
776
776
// Parse an int; if parsing fails, call the condition handler and
777
777
// return whatever it returns.
778
778
fn parse_int(x: &str) -> int {
779
- match from_str::<int> (x) {
779
+ match int::from_str (x) {
780
780
Some(v) => v,
781
781
None => malformed_int::cond.raise(x.to_owned())
782
782
}
@@ -833,8 +833,8 @@ There are three other things to note in this variant of the example program:
833
833
so long as the ` raise ` occurs within a callee (of any depth) of the logic protected by the ` trap ` call,
834
834
it will invoke the handler.
835
835
836
- - This variant insulates callers from a design choice in the library:
837
- the ` from_str ` function was designed to return an ` Option<int> ` ,
836
+ - This variant insulates callers from a design choice in the ` int ` library:
837
+ the ` int:: from_str` function was designed to return an ` Option<int> ` ,
838
838
but this program insulates callers from that choice,
839
839
routing all ` None ` values that arise from parsing integers in this file into the condition.
840
840
@@ -873,4 +873,4 @@ To compensate for this risk, correct C++ and Java code must program in an extrem
873
873
or else risk introducing silent and very difficult-to-debug errors due to control resuming in a corrupted heap after a caught exception.
874
874
These errors are frequently memory-safety errors, which Rust strives to eliminate,
875
875
and so Rust unwinding is unrecoverable within a single task:
876
- once unwinding starts, the entire local heap of a task is destroyed and the task is terminated.
876
+ once unwinding starts, the entire local heap of a task is destroyed and the task is terminated.
0 commit comments