It makes sense to name the function arguments with the same name as the struct
fields, but having to repeat the `email` and `username` field names and
variables is a bit tedious. If the struct had more fields, repeating each name
-would get even more annoying. Luckily, there's a convenient shorthand!
+would get even more annoying. Luckily, there’s a convenient shorthand!
### Using the Field Init Shorthand when Variables and Fields Have the Same Name
<span class="caption">Listing 5-6: Creating a new `User` instance using some of
the values from `user1`</span>
-Using struct update syntax, we can achieve the same effect with less code,
+Using struct update syntax, we can achieve the same effect with less code, as
shown in Listing 5-7. The syntax `..` specifies that the remaining fields not
explicitly set should have the same value as the fields in the given instance.
};
```
-<span class="caption">Listing 5-7: Using struct update syntax to set a new
+<span class="caption">Listing 5-7: Using struct update syntax to set new
`email` and `username` values for a `User` instance but use the rest of the
values from the fields of the instance in the `user1` variable</span>
### Tuple Structs without Named Fields to Create Different Types
-We can also define structs that look similar to tuples, called *tuple structs*,
-that have the added meaning the struct name provides, but don’t have names
-associated with their fields, just the types of the fields. Tuple structs are
-useful when you want to give the whole tuple a name and make the tuple be a
-different type than other tuples, but naming each field as in a regular struct
-would be verbose or redundant.
+We can also define structs that look similar to tuples (which were discussed in
+Chapter 3), called *tuple structs*, that have the added meaning the struct name
+provides, but don’t have names associated with their fields; rather, they just
+have the types of the fields. Tuple structs are useful when you want to give
+the whole tuple a name and make the tuple be a different type than other
+tuples, but naming each field as in a regular struct would be verbose or
+redundant.
To define a tuple struct you start with the `struct` keyword and the struct
name followed by the types in the tuple. For example, here are definitions and
even though the fields within the struct have the same types. For example, a
function that takes a parameter of type `Color` cannot take a `Point` as an
argument, even though both types are made up of three `i32` values. Otherwise,
-tuple struct instances behave like tuples, which we covered in Chapter 3: you
-can destructure them into their individual pieces, you can use a `.` followed
-by the index to access an individual value, and so on.
+tuple struct instances behave like tuples: you can destructure them into their
+individual pieces and you can use a `.` followed by the index to access an
+individual value, and so on.
### Unit-Like Structs without Any Fields
*unit-like structs* since they behave similarly to `()`, the unit type.
Unit-like structs can be useful in situations such as when you need to
implement a trait on some type, but you don’t have any data that you want to
-store in the type itself. We’ll be discussing traits in Chapter 10.
+store in the type itself. We’ll discuss traits in Chapter 10.
> ### Ownership of Struct Data
>
> data to be valid for as long as the entire struct is valid.
>
> It’s possible for structs to store references to data owned by something else,
-> but to do so requires the use of *lifetimes*, a Rust feature that is discussed
-> in Chapter 10. Lifetimes ensure that the data referenced by a struct is valid
-> for as long as the struct is. Let’s say you try to store a reference in a
-> struct without specifying lifetimes, like this:
+> but to do so requires the use of *lifetimes*, a Rust feature that we’ll
+> discuss in Chapter 10. Lifetimes ensure that the data referenced by a struct
+> is valid for as long as the struct is. Let’s say you try to store a reference
+> in a struct without specifying lifetimes, like this:
>
> <span class="filename">Filename: src/main.rs</span>
>
> | ^ expected lifetime parameter
> ```
>
-> We’ll discuss how to fix these errors so you can store references in structs
-> in Chapter 10, but for now, we’ll fix errors like these using owned types like
-> `String` instead of references like `&str`.
+> In Chapter 10, we’ll discuss how to fix these errors so you can store
+> references in structs, but for now, we’ll fix errors like these using owned
+> types like `String` instead of references like `&str`.
projects / rustc.git / blobdiff