rust
/
book
mirror of https://github.com/rust-lang/book
1
0
Fork 0
Code Issues Releases Wiki Activity

Remove comments that are no longer relevant

This commit is contained in:
Carol (Nichols || Goulding) 2017-02-19 21:52:06 -05:00
parent fcfa44d6e6
commit 752f1c05d1
4 changed files with 0 additions and 298 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

149
nostarch/chapter09.md
View File

@ -33,8 +33,6 @@ program will print a failure message, unwind and clean up the stack, and then
quit. The most common situation this occurs in is when a bug of some kind has
been detected and it's not clear to the programmer how to handle the error.
<!-- PROD: START BOX -->
> #### Unwinding
> By default, when a `panic!` occurs, the program starts
> *unwinding*, which means Rust walks back up the stack and cleans up the data
@ -52,8 +50,6 @@ been detected and it's not clear to the programmer how to handle the error.
> panic = 'abort'
> ```
<!-- PROD: END BOX -->
Let's try calling `panic!()` with a simple program:
<span class="filename">Filename: src/main.rs</span>
@ -228,21 +224,6 @@ enum Result<T, E> {
}
```
<!-- Would it make sense for this to be something like:
```
enum Result<T, E> {
Ok(T) => successful_result,
Err(E) => error,
}
```
instead? Then you could concretely explain the returned result.
-->
<!-- This notation looks similar to a `match`, but it's not a `match`, so we
think this would be confusing. We've tried to clarify better in the text.
/Carol -->
The `T` and `E` are generic type parameters; we'll go into generics in more
detail in Chapter 10. What you need to know right now is that `T` represents
the type of the value that will be returned in a success case within the `Ok`
@ -316,23 +297,11 @@ In the case where `File::open` succeeds, the value we will have in the variable
it fails, the value in `f` will be an instance of `Err` that contains more
information about the kind of error that happened.
<!--Can you say explicitly why there being many ways things can fail means we
use the result type? Also, are we importing the File type from the standard
crate here? That seems worth mentioning. -->
<!-- We think it would be repetitive to point out every example that imports a
type from the standard library. We're past the Modules Chapter 7 "Importing
Names With Use" section that explains the concept in depth, as well as multiple
examples in the Hash maps section of Chapter 8 that show how and why to import
types from the standard library. /Carol -->
We need to add to the code from Listing 9-2 to take different actions depending
on the value `File::open` returned. Listing 9-3 shows one way to handle the
`Result` with a basic tool: the `match` expression that we learned about in
Chapter 6.
<!-- I'll ghost everything except the match statement lines in the libreoffice
file /Carol -->
<figure>
<span class="filename">Filename: src/main.rs</span>
@ -358,15 +327,6 @@ might have
</figcaption>
</figure>
<!-- So we don't need the Result keyword in this code example? And what is the
{:?} syntax, can you include a line about that? -->
<!-- We've added an explanation that Result is like Option in that it's
imported into the prelude, which the reader should be familiar with. We
explained the {:?} syntax in Structs, chapter 5, in the section "Adding Useful
Functionality with Derived Traits". It's the debug format. Having to re-explain
multiple concepts that are not the primary focus of this example really
obscures the point of the section. /Carol -->
Note that, like the `Option` enum, the `Result` enum and its variants have been
imported in the prelude, so we don't need to specify `Result::` before the `Ok`
and `Err` variants in the `match` arms.
@ -386,11 +346,6 @@ thread 'main' panicked at 'There was a problem opening the file: Error { repr:
Os { code: 2, message: "No such file or directory" } }', src/main.rs:8
```
<!-- Do we have to manually print the error message, or does it show when we
run the program? -->
<!-- No, the `panic!` macro prints what we give to it, which we covered in the
section previous to this one. /Carol -->
### Matching on Different Errors
The code in Listing 9-3 will `panic!` no matter the reason that `File::open`
@ -433,8 +388,6 @@ Listing 9-4: Handling different kinds of errors in different ways
</figcaption>
</figure>
<!-- I will add ghosting and wingdings here in libreoffice /Carol -->
The type of the value that `File::open` returns inside the `Err` variant is
`io::Error`, which is a struct provided by the standard library. This struct
has a method `kind` that we can call to get an `io::ErrorKind` value.
@ -471,15 +424,6 @@ in Listing 9-3. If the `Result` value is the `Ok` variant, `unwrap` will return
the value inside the `Ok`. If the `Result` is the `Err` variant, `unwrap` will
call the `panic!` macro for us.
<!-- Can you explain a bit more what unwrap() does---you mean every time we
cause a panic it calls the unwrap method? -->
<!-- I'm not sure how the conclusion "every time we cause a panic it calls the
unwrap method" follows from the text that was here, but I've tried to reword.
Please let us know what part of the text specifically is implying that here so
that we can be sure that we've fixed it. /Carol -->
<!-- I'll ghost everything except `unwrap()` in the libreoffice file /Carol -->
```rust,should_panic
use std::fs::File;
@ -488,15 +432,6 @@ fn main() {
}
```
<!-- Can you talk ore about the syntax here, how it differs? It looks like
there aren't generics here for T and E. How is this still related to Result? -->
<!-- I'm not sure how to make this clearer. We're chaining the method call onto
the return value of the `File::open` function, which hasn't changed. The reader
should understand method calls by now. T and E are part of the *definition* of
the Result type, since Listing 9-2 we've been talking about *using* a Result
instance. Listings 9-2, 9-3, and 9-4 don't contain T and E either, so I'm not
sure why it's confusing that this code doesn't contain T and E. /Carol -->
If we run this code without a *hello.txt* file, we'll see an error message from
the `panic` call that the `unwrap` method makes:
@ -511,8 +446,6 @@ There's another method similar to `unwrap` that lets us also choose the
providing good error messages can convey your intent and make tracking down the
source of a panic easier. The syntax of`expect` looks like this:
<!-- I'll ghost everything except `expect(...)` in the libreoffice file /Carol -->
```rust,should_panic
use std::fs::File;
@ -531,24 +464,6 @@ thread 'main' panicked at 'Failed to open hello.txt: Error { repr: Os { code:
2, message: "No such file or directory" } }', ../src/libcore/result.rs:837
```
<!-- I added the above paragraph, can you review it and correct it as
necessary? So this is like what we did in Listing 9-3?-->
<!-- Yes, the implementations for both `unwrap` and `expect` are similar to 9-3,
which we want to show so that the reader knows they don't have to write out all
of 9-3 every time they have a `Result` value. Does this comment mean your
earlier comments in this section are moot? /Carol -->
<!-- Is panic used for both types of errors? The introduction makes it seem as
though it's only for unrecoverable errors -->
<!-- When you call panic, you are causing the program to crash and therefore
creating an unrecoverable error. You can choose to do that at any time, even
when there are *no* errors. There's nothing that prevents you from calling
`panic!` inappropriately, which is why the "to panic or not to panic" section
goes over the criteria the reader should use to decide if they're in a
situation that's recoverable or not. I've actually moved the text that was here
into that section to keep that whole discussion together. /Carol
-->
### Propagating Errors
When writing a function whose implementation calls something that might fail,
@ -558,12 +473,6 @@ caller know about the error so they can decide what to do. This is known as
might be more information or logic that dictates how the error should be
handled than what you have available in the context of your code.
<!-- What's the benefit/result of returning the error to the code that called
the function, besides putting off handling it---can you lay that out? -->
<!-- We're giving control/decision making ability to the code that's calling
our code. I've tried to be more explicit here; please let me know what could be
improved if it's still not clear. /Carol -->
For example, Listing 9-5 shows a function that reads a username from a file. If
the file doesn't exist or can't be read, this function will return those errors
to the code that called this function:
@ -645,15 +554,10 @@ syntax to make this easier: `?`.
### A Shortcut for Propagating Errors: `?`
<!-- The `?` ended up stabilizing in 1.13 and is quickly becoming preferred over
`try!`, so we decided to only cover `?`. /Carol -->
Listing 9-6 shows an implementation of `read_username_from_file` that has the
same functionality as it had in Listing 9-5, but this implementation uses the
question mark:
<!-- I'll ghost everything except the question mark in libreoffice. /Carol -->
<figure>
```rust
@ -675,11 +579,6 @@ Listing 9-6: A function that returns errors to the calling code using `?`
</figcaption>
</figure>
<!-- Below, are we talking about what just the ? operator does, or what the
program with the ? operator does? -->
<!-- I'm not sure what the difference is. We're talking about what the ? does
in the context of this program... /Carol -->
The `?` placed after a `Result` value is defined to work the exact same way as
the`match` expressions we defined to handle the `Result` values in Listing 9-5.
If the value of the `Result` is an `Ok`, the value inside the `Ok` will get
@ -712,10 +611,6 @@ fn read_username_from_file() -> Result<String, io::Error> {
}
```
<!-- Can you explain what is happening in this code and how it differs? -->
<!-- I've tried to make it even clearer that the functionality does NOT differ
/Carol -->
We've moved the creation of the new `String` in `s` to the beginning of the
function; that part hasn't changed. Instead of creating a variable `f`, we've
chained the call to `read_to_string` directly onto the result of
@ -727,32 +622,12 @@ Listing 9-6, this is just a different, more ergonomic way to write it.
#### `?` Can Only Be Used in Functions That Return `Result`
<!-- I think we need a new heading here, could you suggest something? I'm sure
there's a better way to phrase this!-->
<!-- I've tried, but I'm not really sure how to say it any more succinctly than
this, I'm not sure if it's better than what you suggested /Carol -->
The `?` can only be used in functions that have a return type of `Result`,
since it is defined to work in exactly the same way as the `match` expression
we defined in Listing 9-5. The part of the `match` that requires a return type
of `Result` is `return Err(e)`, so the return type of the function must be a
`Result` to be compatible with this `return`.
<!-- Which functions return a Result and how would the reader know? I'm also not
sure what you mean by "expand", that they have the same functionality (but
condensed!)? -->
<!-- You can tell what any function returns by looking at the return type
defined in the function signature, I'm not sure what part of Chapter 3 wasn't
clear enough to convey that. The reader should be comfortable with function
signatures by this point, and could also use the API docs to tell what a
function returns.
I've reworded to remove the word expand, but yes, we meant "functionally
equivalent to replacing it with the longer code"
/Carol
-->
Let's look at what happens if use `try!` in the `main` function, which you'll
recall has a return type of `()`:
@ -845,12 +720,6 @@ situation. If you can ensure by manually inspecting the code that you'll never
have an `Err` variant, it is perfectly acceptable to call `unwrap`. Here's an
example:
<!-- If we know that there won't be an error, why do we still need to use
unwrap()? Can you clarify that in the text? -->
<!-- Because you still have to extract the value from the `Ok`; knowing there
won't be an error doesn't change the types. I've tried to clarify in the
paragraph above and again below. /Carol-->
```rust
use std::net::IpAddr;
@ -922,12 +791,6 @@ even compile, so your function doesn't have to check for that case at runtime.
Another example is using an unsigned integer type like `u32`, which ensures the
parameter is never negative.
<!-- Can you go into more detail explaining this last sentence? Why is a type
better to use than an Option?-->
<!-- I tried to reword, but I'm not sure if I made it any clearer. You don't
have to have extra checks, so your code is simpler; I'm not sure why it's not
clear that simpler is better. /Carol -->
### Creating Custom Types for Validation
Let's take the idea of using Rust's type system to ensure we have a valid value
@ -964,8 +827,6 @@ loop {
}
```
<!-- I'll add wingding numbers in the libreoffice file /Carol -->
The `if` expression checks to see if our value is out of range, tells the user
about the problem, and calls `continue` to start the next iteration of the loop
and ask for another guess. After the `if` expression, we can proceed with the
@ -1016,8 +877,6 @@ Listing 9-8: A `Guess` type that will only continue with values between 1 and
</figcaption>
</figure>
<!-- I'll add wingding numbers in the libreoffice file /Carol -->
First, we define a struct named `Guess` that has a field named `value` that
holds a `u32`. This is where the number will be stored.
@ -1035,14 +894,6 @@ in the API documentation that you create in Chapter 14. If `value` does pass
the test, we create a new `Guess` with its `value` field set to the `value`
parameter, and return the `Guess`.
<!-- I'm not sure if you mean the function that creates the guess type (so
listing 9-8) or the function that uses the guess type, below. You mean the
wider function needs a way to signal that there's a bug leading to contract
violation? -->
<!-- I'm not sure what part is confusing, and I'm not sure what you mean by
"wider function". I hope the slower explanation of the code has cleared
this up; please provide more detail on what's confusing if not. /Carol -->
Next, we implement a method named `value` that borrows `self`, doesn't have any
other parameters, and returns a `u32`. This is a kind of method sometimes called
a *getter*, since its purpose is to get some data from its fields and return

4
src/ch09-01-unrecoverable-errors-with-panic.md
View File

@ -6,8 +6,6 @@ program will print a failure message, unwind and clean up the stack, and then
quit. The most common situation this occurs in is when a bug of some kind has
been detected and it's not clear to the programmer how to handle the error.
<!-- PROD: START BOX -->
> #### Unwinding
> By default, when a `panic!` occurs, the program starts
> *unwinding*, which means Rust walks back up the stack and cleans up the data
@ -25,8 +23,6 @@ been detected and it's not clear to the programmer how to handle the error.
> panic = 'abort'
> ```
<!-- PROD: END BOX -->
Let's try calling `panic!()` with a simple program:
<span class="filename">Filename: src/main.rs</span>

121
src/ch09-02-recoverable-errors-with-result.md
View File

@ -17,21 +17,6 @@ enum Result<T, E> {
}
```
<!-- Would it make sense for this to be something like:
```
enum Result<T, E> {
Ok(T) => successful_result,
Err(E) => error,
}
```
instead? Then you could concretely explain the returned result.
-->
<!-- This notation looks similar to a `match`, but it's not a `match`, so we
think this would be confusing. We've tried to clarify better in the text.
/Carol -->
The `T` and `E` are generic type parameters; we'll go into generics in more
detail in Chapter 10. What you need to know right now is that `T` represents
the type of the value that will be returned in a success case within the `Ok`
@ -105,23 +90,11 @@ In the case where `File::open` succeeds, the value we will have in the variable
it fails, the value in `f` will be an instance of `Err` that contains more
information about the kind of error that happened.
<!--Can you say explicitly why there being many ways things can fail means we
use the result type? Also, are we importing the File type from the standard
crate here? That seems worth mentioning. -->
<!-- We think it would be repetitive to point out every example that imports a
type from the standard library. We're past the Modules Chapter 7 "Importing
Names With Use" section that explains the concept in depth, as well as multiple
examples in the Hash maps section of Chapter 8 that show how and why to import
types from the standard library. /Carol -->
We need to add to the code from Listing 9-2 to take different actions depending
on the value `File::open` returned. Listing 9-3 shows one way to handle the
`Result` with a basic tool: the `match` expression that we learned about in
Chapter 6.
<!-- I'll ghost everything except the match statement lines in the libreoffice
file /Carol -->
<figure>
<span class="filename">Filename: src/main.rs</span>
@ -147,15 +120,6 @@ might have
</figcaption>
</figure>
<!-- So we don't need the Result keyword in this code example? And what is the
{:?} syntax, can you include a line about that? -->
<!-- We've added an explanation that Result is like Option in that it's
imported into the prelude, which the reader should be familiar with. We
explained the {:?} syntax in Structs, chapter 5, in the section "Adding Useful
Functionality with Derived Traits". It's the debug format. Having to re-explain
multiple concepts that are not the primary focus of this example really
obscures the point of the section. /Carol -->
Note that, like the `Option` enum, the `Result` enum and its variants have been
imported in the prelude, so we don't need to specify `Result::` before the `Ok`
and `Err` variants in the `match` arms.
@ -175,11 +139,6 @@ thread 'main' panicked at 'There was a problem opening the file: Error { repr:
Os { code: 2, message: "No such file or directory" } }', src/main.rs:8
```
<!-- Do we have to manually print the error message, or does it show when we
run the program? -->
<!-- No, the `panic!` macro prints what we give to it, which we covered in the
section previous to this one. /Carol -->
### Matching on Different Errors
The code in Listing 9-3 will `panic!` no matter the reason that `File::open`
@ -222,8 +181,6 @@ Listing 9-4: Handling different kinds of errors in different ways
</figcaption>
</figure>
<!-- I will add ghosting and wingdings here in libreoffice /Carol -->
The type of the value that `File::open` returns inside the `Err` variant is
`io::Error`, which is a struct provided by the standard library. This struct
has a method `kind` that we can call to get an `io::ErrorKind` value.
@ -260,15 +217,6 @@ in Listing 9-3. If the `Result` value is the `Ok` variant, `unwrap` will return
the value inside the `Ok`. If the `Result` is the `Err` variant, `unwrap` will
call the `panic!` macro for us.
<!-- Can you explain a bit more what unwrap() does---you mean every time we
cause a panic it calls the unwrap method? -->
<!-- I'm not sure how the conclusion "every time we cause a panic it calls the
unwrap method" follows from the text that was here, but I've tried to reword.
Please let us know what part of the text specifically is implying that here so
that we can be sure that we've fixed it. /Carol -->
<!-- I'll ghost everything except `unwrap()` in the libreoffice file /Carol -->
```rust,should_panic
use std::fs::File;
@ -277,15 +225,6 @@ fn main() {
}
```
<!-- Can you talk ore about the syntax here, how it differs? It looks like
there aren't generics here for T and E. How is this still related to Result? -->
<!-- I'm not sure how to make this clearer. We're chaining the method call onto
the return value of the `File::open` function, which hasn't changed. The reader
should understand method calls by now. T and E are part of the *definition* of
the Result type, since Listing 9-2 we've been talking about *using* a Result
instance. Listings 9-2, 9-3, and 9-4 don't contain T and E either, so I'm not
sure why it's confusing that this code doesn't contain T and E. /Carol -->
If we run this code without a *hello.txt* file, we'll see an error message from
the `panic` call that the `unwrap` method makes:
@ -300,8 +239,6 @@ There's another method similar to `unwrap` that lets us also choose the
providing good error messages can convey your intent and make tracking down the
source of a panic easier. The syntax of`expect` looks like this:
<!-- I'll ghost everything except `expect(...)` in the libreoffice file /Carol -->
```rust,should_panic
use std::fs::File;
@ -320,24 +257,6 @@ thread 'main' panicked at 'Failed to open hello.txt: Error { repr: Os { code:
2, message: "No such file or directory" } }', ../src/libcore/result.rs:837
```
<!-- I added the above paragraph, can you review it and correct it as
necessary? So this is like what we did in Listing 9-3?-->
<!-- Yes, the implementations for both `unwrap` and `expect` are similar to 9-3,
which we want to show so that the reader knows they don't have to write out all
of 9-3 every time they have a `Result` value. Does this comment mean your
earlier comments in this section are moot? /Carol -->
<!-- Is panic used for both types of errors? The introduction makes it seem as
though it's only for unrecoverable errors -->
<!-- When you call panic, you are causing the program to crash and therefore
creating an unrecoverable error. You can choose to do that at any time, even
when there are *no* errors. There's nothing that prevents you from calling
`panic!` inappropriately, which is why the "to panic or not to panic" section
goes over the criteria the reader should use to decide if they're in a
situation that's recoverable or not. I've actually moved the text that was here
into that section to keep that whole discussion together. /Carol
-->
### Propagating Errors
When writing a function whose implementation calls something that might fail,
@ -347,12 +266,6 @@ caller know about the error so they can decide what to do. This is known as
might be more information or logic that dictates how the error should be
handled than what you have available in the context of your code.
<!-- What's the benefit/result of returning the error to the code that called
the function, besides putting off handling it---can you lay that out? -->
<!-- We're giving control/decision making ability to the code that's calling
our code. I've tried to be more explicit here; please let me know what could be
improved if it's still not clear. /Carol -->
For example, Listing 9-5 shows a function that reads a username from a file. If
the file doesn't exist or can't be read, this function will return those errors
to the code that called this function:
@ -434,15 +347,10 @@ syntax to make this easier: `?`.
### A Shortcut for Propagating Errors: `?`
<!-- The `?` ended up stabilizing in 1.13 and is quickly becoming preferred over
`try!`, so we decided to only cover `?`. /Carol -->
Listing 9-6 shows an implementation of `read_username_from_file` that has the
same functionality as it had in Listing 9-5, but this implementation uses the
question mark:
<!-- I'll ghost everything except the question mark in libreoffice. /Carol -->
<figure>
```rust
@ -464,11 +372,6 @@ Listing 9-6: A function that returns errors to the calling code using `?`
</figcaption>
</figure>
<!-- Below, are we talking about what just the ? operator does, or what the
program with the ? operator does? -->
<!-- I'm not sure what the difference is. We're talking about what the ? does
in the context of this program... /Carol -->
The `?` placed after a `Result` value is defined to work the exact same way as
the`match` expressions we defined to handle the `Result` values in Listing 9-5.
If the value of the `Result` is an `Ok`, the value inside the `Ok` will get
@ -501,10 +404,6 @@ fn read_username_from_file() -> Result<String, io::Error> {
}
```
<!-- Can you explain what is happening in this code and how it differs? -->
<!-- I've tried to make it even clearer that the functionality does NOT differ
/Carol -->
We've moved the creation of the new `String` in `s` to the beginning of the
function; that part hasn't changed. Instead of creating a variable `f`, we've
chained the call to `read_to_string` directly onto the result of
@ -516,32 +415,12 @@ Listing 9-6, this is just a different, more ergonomic way to write it.
#### `?` Can Only Be Used in Functions That Return `Result`
<!-- I think we need a new heading here, could you suggest something? I'm sure
there's a better way to phrase this!-->
<!-- I've tried, but I'm not really sure how to say it any more succinctly than
this, I'm not sure if it's better than what you suggested /Carol -->
The `?` can only be used in functions that have a return type of `Result`,
since it is defined to work in exactly the same way as the `match` expression
we defined in Listing 9-5. The part of the `match` that requires a return type
of `Result` is `return Err(e)`, so the return type of the function must be a
`Result` to be compatible with this `return`.
<!-- Which functions return a Result and how would the reader know? I'm also not
sure what you mean by "expand", that they have the same functionality (but
condensed!)? -->
<!-- You can tell what any function returns by looking at the return type
defined in the function signature, I'm not sure what part of Chapter 3 wasn't
clear enough to convey that. The reader should be comfortable with function
signatures by this point, and could also use the API docs to tell what a
function returns.
I've reworded to remove the word expand, but yes, we meant "functionally
equivalent to replacing it with the longer code"
/Carol
-->
Let's look at what happens if use `try!` in the `main` function, which you'll
recall has a return type of `()`:

24
src/ch09-03-to-panic-or-not-to-panic.md
View File

@ -48,12 +48,6 @@ situation. If you can ensure by manually inspecting the code that you'll never
have an `Err` variant, it is perfectly acceptable to call `unwrap`. Here's an
example:
<!-- If we know that there won't be an error, why do we still need to use
unwrap()? Can you clarify that in the text? -->
<!-- Because you still have to extract the value from the `Ok`; knowing there
won't be an error doesn't change the types. I've tried to clarify in the
paragraph above and again below. /Carol-->
```rust
use std::net::IpAddr;
@ -125,12 +119,6 @@ even compile, so your function doesn't have to check for that case at runtime.
Another example is using an unsigned integer type like `u32`, which ensures the
parameter is never negative.
<!-- Can you go into more detail explaining this last sentence? Why is a type
better to use than an Option?-->
<!-- I tried to reword, but I'm not sure if I made it any clearer. You don't
have to have extra checks, so your code is simpler; I'm not sure why it's not
clear that simpler is better. /Carol -->
### Creating Custom Types for Validation
Let's take the idea of using Rust's type system to ensure we have a valid value
@ -167,8 +155,6 @@ loop {
}
```
<!-- I'll add wingding numbers in the libreoffice file /Carol -->
The `if` expression checks to see if our value is out of range, tells the user
about the problem, and calls `continue` to start the next iteration of the loop
and ask for another guess. After the `if` expression, we can proceed with the
@ -219,8 +205,6 @@ Listing 9-8: A `Guess` type that will only continue with values between 1 and
</figcaption>
</figure>
<!-- I'll add wingding numbers in the libreoffice file /Carol -->
First, we define a struct named `Guess` that has a field named `value` that
holds a `u32`. This is where the number will be stored.
@ -238,14 +222,6 @@ in the API documentation that you create in Chapter 14. If `value` does pass
the test, we create a new `Guess` with its `value` field set to the `value`
parameter, and return the `Guess`.
<!-- I'm not sure if you mean the function that creates the guess type (so
listing 9-8) or the function that uses the guess type, below. You mean the
wider function needs a way to signal that there's a bug leading to contract
violation? -->
<!-- I'm not sure what part is confusing, and I'm not sure what you mean by
"wider function". I hope the slower explanation of the code has cleared
this up; please provide more detail on what's confusing if not. /Carol -->
Next, we implement a method named `value` that borrows `self`, doesn't have any
other parameters, and returns a `u32`. This is a kind of method sometimes called
a *getter*, since its purpose is to get some data from its fields and return