2021-04-24 13:15:34 -04:00
|
|
|
# INTRO
|
|
|
|
|
|
|
|
[[exercises]]
|
|
|
|
name = "intro1"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/00_intro/intro1.rs"
|
2021-04-24 13:15:34 -04:00
|
|
|
mode = "compile"
|
|
|
|
hint = """
|
2023-10-16 07:37:12 -04:00
|
|
|
Remove the `I AM NOT DONE` comment in the `exercises/intro00/intro1.rs` file
|
2022-07-11 07:20:18 -04:00
|
|
|
to move on to the next exercise."""
|
2021-04-24 13:15:34 -04:00
|
|
|
|
|
|
|
[[exercises]]
|
|
|
|
name = "intro2"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/00_intro/intro2.rs"
|
2021-04-24 13:15:34 -04:00
|
|
|
mode = "compile"
|
|
|
|
hint = """
|
2023-10-20 12:31:56 -04:00
|
|
|
The compiler is informing us that we've got the name of the print macro wrong, and has suggested an alternative."""
|
2021-04-24 13:15:34 -04:00
|
|
|
|
2019-03-06 15:47:00 -05:00
|
|
|
# VARIABLES
|
|
|
|
|
|
|
|
[[exercises]]
|
2019-11-11 09:46:32 -05:00
|
|
|
name = "variables1"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/01_variables/variables1.rs"
|
2019-03-06 15:47:00 -05:00
|
|
|
mode = "compile"
|
2019-11-11 10:51:38 -05:00
|
|
|
hint = """
|
2023-08-26 17:25:12 -04:00
|
|
|
The declaration in the first line in the main function is missing a keyword
|
|
|
|
that is needed in Rust to create a new variable binding."""
|
2019-03-06 15:47:00 -05:00
|
|
|
|
|
|
|
[[exercises]]
|
2019-11-11 09:46:32 -05:00
|
|
|
name = "variables2"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/01_variables/variables2.rs"
|
2019-03-06 15:47:00 -05:00
|
|
|
mode = "compile"
|
2019-11-11 10:51:38 -05:00
|
|
|
hint = """
|
|
|
|
The compiler message is saying that Rust cannot infer the type that the
|
|
|
|
variable binding `x` has with what is given here.
|
2023-09-28 18:39:51 -04:00
|
|
|
|
|
|
|
What happens if you annotate the first line in the main function with a type
|
|
|
|
annotation?
|
|
|
|
|
|
|
|
What if you give `x` a value?
|
|
|
|
|
2019-11-11 10:51:38 -05:00
|
|
|
What if you do both?
|
2023-09-28 18:39:51 -04:00
|
|
|
|
|
|
|
What type should `x` be, anyway?
|
|
|
|
|
|
|
|
What if `x` is the same type as `10`? What if it's a different type?"""
|
2019-03-06 15:47:00 -05:00
|
|
|
|
|
|
|
[[exercises]]
|
2019-11-11 09:46:32 -05:00
|
|
|
name = "variables3"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/01_variables/variables3.rs"
|
2019-03-06 15:47:00 -05:00
|
|
|
mode = "compile"
|
2019-11-11 10:51:38 -05:00
|
|
|
hint = """
|
2023-09-28 18:39:51 -04:00
|
|
|
Oops! In this exercise, we have a variable binding that we've created on in the
|
|
|
|
first line in the `main` function, and we're trying to use it in the next line,
|
2023-08-26 17:25:12 -04:00
|
|
|
but we haven't given it a value.
|
2023-09-28 18:39:51 -04:00
|
|
|
|
|
|
|
We can't print out something that isn't there; try giving `x` a value!
|
|
|
|
|
2022-07-11 07:43:41 -04:00
|
|
|
This is an error that can cause bugs that's very easy to make in any
|
|
|
|
programming language -- thankfully the Rust compiler has caught this for us!"""
|
2019-03-06 15:47:00 -05:00
|
|
|
|
|
|
|
[[exercises]]
|
2019-11-11 09:46:32 -05:00
|
|
|
name = "variables4"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/01_variables/variables4.rs"
|
2019-03-06 15:47:00 -05:00
|
|
|
mode = "compile"
|
2019-11-11 10:51:38 -05:00
|
|
|
hint = """
|
2022-07-11 07:43:41 -04:00
|
|
|
In Rust, variable bindings are immutable by default. But here we're trying
|
2023-09-28 18:39:51 -04:00
|
|
|
to reassign a different value to `x`! There's a keyword we can use to make
|
2022-07-11 07:43:41 -04:00
|
|
|
a variable binding mutable instead."""
|
2019-03-06 15:47:00 -05:00
|
|
|
|
2020-01-14 15:06:43 -05:00
|
|
|
[[exercises]]
|
|
|
|
name = "variables5"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/01_variables/variables5.rs"
|
2020-01-14 15:06:43 -05:00
|
|
|
mode = "compile"
|
|
|
|
hint = """
|
2023-09-28 18:39:51 -04:00
|
|
|
In `variables4` we already learned how to make an immutable variable mutable
|
|
|
|
using a special keyword. Unfortunately this doesn't help us much in this
|
|
|
|
exercise because we want to assign a different typed value to an existing
|
|
|
|
variable. Sometimes you may also like to reuse existing variable names because
|
|
|
|
you are just converting values to different types like in this exercise.
|
|
|
|
|
2020-01-14 15:06:43 -05:00
|
|
|
Fortunately Rust has a powerful solution to this problem: 'Shadowing'!
|
2023-09-28 18:39:51 -04:00
|
|
|
You can read more about 'Shadowing' in the book's section 'Variables and
|
|
|
|
Mutability':
|
2020-04-12 13:35:20 -04:00
|
|
|
https://doc.rust-lang.org/book/ch03-01-variables-and-mutability.html#shadowing
|
2023-09-28 18:39:51 -04:00
|
|
|
|
2020-01-14 15:06:43 -05:00
|
|
|
Try to solve this exercise afterwards using this technique."""
|
|
|
|
|
2020-04-14 04:13:20 -04:00
|
|
|
[[exercises]]
|
|
|
|
name = "variables6"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/01_variables/variables6.rs"
|
2020-04-14 04:13:20 -04:00
|
|
|
mode = "compile"
|
|
|
|
hint = """
|
2020-08-27 13:51:19 -04:00
|
|
|
We know about variables and mutability, but there is another important type of
|
2022-02-24 21:35:43 -05:00
|
|
|
variable available: constants.
|
2023-09-28 18:39:51 -04:00
|
|
|
|
|
|
|
Constants are always immutable and they are declared with keyword `const` rather
|
|
|
|
than keyword `let`.
|
|
|
|
|
2020-04-14 04:13:20 -04:00
|
|
|
Constants types must also always be annotated.
|
|
|
|
|
2023-09-28 18:39:51 -04:00
|
|
|
Read more about constants and the differences between variables and constants
|
|
|
|
under 'Constants' in the book's section 'Variables and Mutability':
|
2022-06-13 15:30:25 -04:00
|
|
|
https://doc.rust-lang.org/book/ch03-01-variables-and-mutability.html#constants
|
2020-04-14 04:13:20 -04:00
|
|
|
"""
|
|
|
|
|
2019-03-06 15:47:00 -05:00
|
|
|
# FUNCTIONS
|
|
|
|
|
|
|
|
[[exercises]]
|
2019-11-11 09:46:32 -05:00
|
|
|
name = "functions1"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/02_functions/functions1.rs"
|
2019-03-06 15:47:00 -05:00
|
|
|
mode = "compile"
|
2019-11-11 10:51:38 -05:00
|
|
|
hint = """
|
|
|
|
This main function is calling a function that it expects to exist, but the
|
|
|
|
function doesn't exist. It expects this function to have the name `call_me`.
|
|
|
|
It expects this function to not take any arguments and not return a value.
|
|
|
|
Sounds a lot like `main`, doesn't it?"""
|
2019-03-06 15:47:00 -05:00
|
|
|
|
|
|
|
[[exercises]]
|
2019-11-11 09:46:32 -05:00
|
|
|
name = "functions2"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/02_functions/functions2.rs"
|
2019-03-06 15:47:00 -05:00
|
|
|
mode = "compile"
|
2019-11-11 10:51:38 -05:00
|
|
|
hint = """
|
|
|
|
Rust requires that all parts of a function's signature have type annotations,
|
|
|
|
but `call_me` is missing the type annotation of `num`."""
|
2019-03-06 15:47:00 -05:00
|
|
|
|
|
|
|
[[exercises]]
|
2019-11-11 09:46:32 -05:00
|
|
|
name = "functions3"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/02_functions/functions3.rs"
|
2019-03-06 15:47:00 -05:00
|
|
|
mode = "compile"
|
2019-11-11 10:51:38 -05:00
|
|
|
hint = """
|
|
|
|
This time, the function *declaration* is okay, but there's something wrong
|
2022-07-12 05:08:29 -04:00
|
|
|
with the place where we're calling the function.
|
2023-09-28 18:39:51 -04:00
|
|
|
|
2022-07-12 05:08:29 -04:00
|
|
|
As a reminder, you can freely play around with different solutions in Rustlings!
|
2023-09-28 18:39:51 -04:00
|
|
|
Watch mode will only jump to the next exercise if you remove the `I AM NOT
|
|
|
|
DONE` comment."""
|
2019-03-06 15:47:00 -05:00
|
|
|
|
|
|
|
[[exercises]]
|
2019-11-11 09:46:32 -05:00
|
|
|
name = "functions4"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/02_functions/functions4.rs"
|
2019-03-06 15:47:00 -05:00
|
|
|
mode = "compile"
|
2019-11-11 10:51:38 -05:00
|
|
|
hint = """
|
2023-08-26 17:25:12 -04:00
|
|
|
The error message points to the function `sale_price` and says it expects a type
|
2023-09-28 18:39:51 -04:00
|
|
|
after the `->`. This is where the function's return type should be -- take a
|
|
|
|
look at the `is_even` function for an example!
|
2022-07-12 05:08:29 -04:00
|
|
|
|
2023-09-28 18:39:51 -04:00
|
|
|
Also: Did you figure out that, technically, `u32` would be the more fitting type
|
2022-07-12 05:08:29 -04:00
|
|
|
for the prices here, since they can't be negative? If so, kudos!"""
|
2019-03-06 15:47:00 -05:00
|
|
|
|
|
|
|
[[exercises]]
|
2019-11-11 09:46:32 -05:00
|
|
|
name = "functions5"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/02_functions/functions5.rs"
|
2019-03-06 15:47:00 -05:00
|
|
|
mode = "compile"
|
2019-11-11 10:51:38 -05:00
|
|
|
hint = """
|
|
|
|
This is a really common error that can be fixed by removing one character.
|
2023-09-28 18:39:51 -04:00
|
|
|
It happens because Rust distinguishes between expressions and statements:
|
|
|
|
expressions return a value based on their operand(s), and statements simply
|
|
|
|
return a `()` type which behaves just like `void` in C/C++ language.
|
|
|
|
|
|
|
|
We want to return a value of `i32` type from the `square` function, but it is
|
|
|
|
returning a `()` type...
|
|
|
|
|
2019-11-11 10:51:38 -05:00
|
|
|
They are not the same. There are two solutions:
|
|
|
|
1. Add a `return` ahead of `num * num;`
|
2019-11-11 10:56:39 -05:00
|
|
|
2. remove `;`, make it to be `num * num`"""
|
2019-03-06 15:47:00 -05:00
|
|
|
|
2020-12-07 09:37:19 -05:00
|
|
|
# IF
|
|
|
|
|
|
|
|
[[exercises]]
|
|
|
|
name = "if1"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/03_if/if1.rs"
|
2020-12-07 09:37:19 -05:00
|
|
|
mode = "test"
|
|
|
|
hint = """
|
|
|
|
It's possible to do this in one line if you would like!
|
2023-09-28 18:39:51 -04:00
|
|
|
|
2020-12-07 09:37:19 -05:00
|
|
|
Some similar examples from other languages:
|
|
|
|
- In C(++) this would be: `a > b ? a : b`
|
|
|
|
- In Python this would be: `a if a > b else b`
|
2023-09-28 18:39:51 -04:00
|
|
|
|
2020-12-07 09:37:19 -05:00
|
|
|
Remember in Rust that:
|
|
|
|
- the `if` condition does not need to be surrounded by parentheses
|
|
|
|
- `if`/`else` conditionals are expressions
|
|
|
|
- Each condition is followed by a `{}` block."""
|
|
|
|
|
|
|
|
[[exercises]]
|
|
|
|
name = "if2"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/03_if/if2.rs"
|
2020-12-07 09:37:19 -05:00
|
|
|
mode = "test"
|
|
|
|
hint = """
|
|
|
|
For that first compiler error, it's important in Rust that each conditional
|
2022-05-22 12:56:26 -04:00
|
|
|
block returns the same type! To get the tests passing, you will need a couple
|
2020-12-07 09:37:19 -05:00
|
|
|
conditions checking different input values."""
|
|
|
|
|
2023-07-03 14:52:13 -04:00
|
|
|
[[exercises]]
|
|
|
|
name = "if3"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/03_if/if3.rs"
|
2023-07-03 14:52:13 -04:00
|
|
|
mode = "test"
|
|
|
|
hint = """
|
2023-09-28 18:39:51 -04:00
|
|
|
In Rust, every arm of an `if` expression has to return the same type of value.
|
|
|
|
Make sure the type is consistent across all arms."""
|
2023-07-03 14:52:13 -04:00
|
|
|
|
2022-07-14 07:01:40 -04:00
|
|
|
# QUIZ 1
|
2019-03-06 15:47:00 -05:00
|
|
|
|
|
|
|
[[exercises]]
|
2020-05-19 12:47:44 -04:00
|
|
|
name = "quiz1"
|
|
|
|
path = "exercises/quiz1.rs"
|
2019-03-06 15:47:00 -05:00
|
|
|
mode = "test"
|
2019-11-11 10:51:38 -05:00
|
|
|
hint = "No hints this time ;)"
|
2019-03-06 15:47:00 -05:00
|
|
|
|
2022-07-12 08:53:56 -04:00
|
|
|
# PRIMITIVE TYPES
|
|
|
|
|
|
|
|
[[exercises]]
|
|
|
|
name = "primitive_types1"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/04_primitive_types/primitive_types1.rs"
|
2022-07-12 08:53:56 -04:00
|
|
|
mode = "compile"
|
|
|
|
hint = "No hints this time ;)"
|
|
|
|
|
|
|
|
[[exercises]]
|
|
|
|
name = "primitive_types2"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/04_primitive_types/primitive_types2.rs"
|
2022-07-12 08:53:56 -04:00
|
|
|
mode = "compile"
|
|
|
|
hint = "No hints this time ;)"
|
|
|
|
|
|
|
|
[[exercises]]
|
|
|
|
name = "primitive_types3"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/04_primitive_types/primitive_types3.rs"
|
2022-07-12 08:53:56 -04:00
|
|
|
mode = "compile"
|
|
|
|
hint = """
|
|
|
|
There's a shorthand to initialize Arrays with a certain size that does not
|
|
|
|
require you to type in 100 items (but you certainly can if you want!).
|
2023-09-28 18:39:51 -04:00
|
|
|
|
2022-07-12 08:53:56 -04:00
|
|
|
For example, you can do:
|
2023-09-28 18:39:51 -04:00
|
|
|
```
|
2022-07-12 08:53:56 -04:00
|
|
|
let array = ["Are we there yet?"; 10];
|
2023-09-28 18:39:51 -04:00
|
|
|
```
|
2022-07-12 08:53:56 -04:00
|
|
|
|
2023-09-28 18:39:51 -04:00
|
|
|
Bonus: what are some other things you could have that would return `true`
|
2022-07-12 08:53:56 -04:00
|
|
|
for `a.len() >= 100`?"""
|
|
|
|
|
|
|
|
[[exercises]]
|
|
|
|
name = "primitive_types4"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/04_primitive_types/primitive_types4.rs"
|
2022-07-12 08:53:56 -04:00
|
|
|
mode = "test"
|
|
|
|
hint = """
|
2023-09-28 18:39:51 -04:00
|
|
|
Take a look at the 'Understanding Ownership -> Slices -> Other Slices' section
|
|
|
|
of the book: https://doc.rust-lang.org/book/ch04-03-slices.html and use the
|
|
|
|
starting and ending (plus one) indices of the items in the `Array` that you
|
|
|
|
want to end up in the slice.
|
2022-07-12 08:53:56 -04:00
|
|
|
|
2023-09-28 18:39:51 -04:00
|
|
|
If you're curious why the first argument of `assert_eq!` does not have an
|
|
|
|
ampersand for a reference since the second argument is areference, take a look
|
|
|
|
at the coercion chapter of the nomicon:
|
2022-07-12 08:53:56 -04:00
|
|
|
https://doc.rust-lang.org/nomicon/coercions.html"""
|
|
|
|
|
|
|
|
[[exercises]]
|
|
|
|
name = "primitive_types5"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/04_primitive_types/primitive_types5.rs"
|
2022-07-12 08:53:56 -04:00
|
|
|
mode = "compile"
|
|
|
|
hint = """
|
2023-09-28 18:39:51 -04:00
|
|
|
Take a look at the 'Data Types -> The Tuple Type' section of the book:
|
2022-07-12 08:53:56 -04:00
|
|
|
https://doc.rust-lang.org/book/ch03-02-data-types.html#the-tuple-type
|
2023-09-28 18:39:51 -04:00
|
|
|
Particularly the part about destructuring (second to last example in the
|
|
|
|
section).
|
|
|
|
|
2022-07-12 08:53:56 -04:00
|
|
|
You'll need to make a pattern to bind `name` and `age` to the appropriate parts
|
|
|
|
of the tuple. You can do it!!"""
|
|
|
|
|
|
|
|
[[exercises]]
|
|
|
|
name = "primitive_types6"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/04_primitive_types/primitive_types6.rs"
|
2022-07-12 08:53:56 -04:00
|
|
|
mode = "test"
|
|
|
|
hint = """
|
|
|
|
While you could use a destructuring `let` for the tuple here, try
|
|
|
|
indexing into it instead, as explained in the last example of the
|
2023-09-28 18:39:51 -04:00
|
|
|
'Data Types -> The Tuple Type' section of the book:
|
2022-07-12 08:53:56 -04:00
|
|
|
https://doc.rust-lang.org/book/ch03-02-data-types.html#the-tuple-type
|
|
|
|
Now you have another tool in your toolbox!"""
|
|
|
|
|
|
|
|
# VECS
|
|
|
|
|
|
|
|
[[exercises]]
|
2022-07-12 09:16:25 -04:00
|
|
|
name = "vecs1"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/05_vecs/vecs1.rs"
|
2022-07-12 08:53:56 -04:00
|
|
|
mode = "test"
|
|
|
|
hint = """
|
|
|
|
In Rust, there are two ways to define a Vector.
|
|
|
|
1. One way is to use the `Vec::new()` function to create a new vector
|
2023-09-28 18:39:51 -04:00
|
|
|
and fill it with the `push()` method.
|
2022-07-12 08:53:56 -04:00
|
|
|
2. The second way, which is simpler is to use the `vec![]` macro and
|
2023-09-28 18:39:51 -04:00
|
|
|
define your elements inside the square brackets.
|
|
|
|
|
2022-07-12 08:53:56 -04:00
|
|
|
Check this chapter: https://doc.rust-lang.org/stable/book/ch08-01-vectors.html
|
|
|
|
of the Rust book to learn more.
|
|
|
|
"""
|
|
|
|
|
|
|
|
[[exercises]]
|
2022-07-12 09:16:25 -04:00
|
|
|
name = "vecs2"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/05_vecs/vecs2.rs"
|
2022-07-12 08:53:56 -04:00
|
|
|
mode = "test"
|
|
|
|
hint = """
|
2023-09-28 18:39:51 -04:00
|
|
|
In the first function we are looping over the Vector and getting a reference to
|
|
|
|
one `element` at a time.
|
|
|
|
|
|
|
|
To modify the value of that `element` we need to use the `*` dereference
|
|
|
|
operator. You can learn more in this chapter of the Rust book:
|
2023-04-08 04:50:50 -04:00
|
|
|
https://doc.rust-lang.org/stable/book/ch08-01-vectors.html#iterating-over-the-values-in-a-vector
|
2022-07-12 09:05:47 -04:00
|
|
|
|
2023-09-28 18:39:51 -04:00
|
|
|
In the second function this dereferencing is not necessary, because the `map`
|
|
|
|
function expects the new value to be returned.
|
|
|
|
|
|
|
|
After you've completed both functions, decide for yourself which approach you
|
|
|
|
like better.
|
2022-07-12 09:05:47 -04:00
|
|
|
|
2023-04-08 04:50:50 -04:00
|
|
|
What do you think is the more commonly used pattern under Rust developers?
|
2022-07-12 08:53:56 -04:00
|
|
|
"""
|
|
|
|
|
2020-12-07 09:37:19 -05:00
|
|
|
# MOVE SEMANTICS
|
|
|
|
|
|
|
|
[[exercises]]
|
|
|
|
name = "move_semantics1"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/06_move_semantics/move_semantics1.rs"
|
2023-09-04 08:20:37 -04:00
|
|
|
mode = "test"
|
2020-12-07 09:37:19 -05:00
|
|
|
hint = """
|
2023-09-28 18:39:51 -04:00
|
|
|
So you've got the "cannot borrow immutable local variable `vec` as mutable"
|
|
|
|
error on the line where we push an element to the vector, right?
|
|
|
|
|
|
|
|
The fix for this is going to be adding one keyword, and the addition is NOT on
|
|
|
|
the line where we push to the vector (where the error is).
|
2022-07-12 09:25:31 -04:00
|
|
|
|
2023-09-28 18:39:51 -04:00
|
|
|
Also: Try accessing `vec0` after having called `fill_vec()`. See what
|
|
|
|
happens!"""
|
2020-12-07 09:37:19 -05:00
|
|
|
|
|
|
|
[[exercises]]
|
|
|
|
name = "move_semantics2"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/06_move_semantics/move_semantics2.rs"
|
2023-09-04 08:20:37 -04:00
|
|
|
mode = "test"
|
2020-12-07 09:37:19 -05:00
|
|
|
hint = """
|
2023-06-12 06:07:18 -04:00
|
|
|
When running this exercise for the first time, you'll notice an error about
|
|
|
|
"borrow of moved value". In Rust, when an argument is passed to a function and
|
|
|
|
it's not explicitly returned, you can't use the original variable anymore.
|
2023-09-28 18:39:51 -04:00
|
|
|
We call this "moving" a variable. When we pass `vec0` into `fill_vec`, it's
|
|
|
|
being "moved" into `vec1`, meaning we can't access `vec0` anymore after the
|
|
|
|
fact.
|
|
|
|
|
|
|
|
Rust provides a couple of different ways to mitigate this issue, feel free to
|
|
|
|
try them all:
|
|
|
|
1. You could make another, separate version of the data that's in `vec0` and
|
|
|
|
pass that to `fill_vec` instead.
|
2020-12-07 09:37:19 -05:00
|
|
|
2. Make `fill_vec` borrow its argument instead of taking ownership of it,
|
2023-09-28 18:39:51 -04:00
|
|
|
and then copy the data within the function (`vec.clone()`) in order to
|
|
|
|
return an owned `Vec<i32>`.
|
2023-06-12 06:07:18 -04:00
|
|
|
"""
|
2020-12-07 09:37:19 -05:00
|
|
|
|
|
|
|
[[exercises]]
|
|
|
|
name = "move_semantics3"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/06_move_semantics/move_semantics3.rs"
|
2023-09-04 08:20:37 -04:00
|
|
|
mode = "test"
|
2020-12-07 09:37:19 -05:00
|
|
|
hint = """
|
|
|
|
The difference between this one and the previous ones is that the first line
|
|
|
|
of `fn fill_vec` that had `let mut vec = vec;` is no longer there. You can,
|
|
|
|
instead of adding that line back, add `mut` in one place that will change
|
|
|
|
an existing binding to be a mutable binding instead of an immutable one :)"""
|
|
|
|
|
|
|
|
[[exercises]]
|
|
|
|
name = "move_semantics4"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/06_move_semantics/move_semantics4.rs"
|
2023-09-04 08:20:37 -04:00
|
|
|
mode = "test"
|
2020-12-07 09:37:19 -05:00
|
|
|
hint = """
|
|
|
|
Stop reading whenever you feel like you have enough direction :) Or try
|
|
|
|
doing one step and then fixing the compiler errors that result!
|
|
|
|
So the end goal is to:
|
|
|
|
- get rid of the first line in main that creates the new vector
|
|
|
|
- so then `vec0` doesn't exist, so we can't pass it to `fill_vec`
|
2023-02-18 14:26:40 -05:00
|
|
|
- `fill_vec` has had its signature changed, which our call should reflect
|
2020-12-07 09:37:19 -05:00
|
|
|
- since we're not creating a new vec in `main` anymore, we need to create
|
2023-09-04 08:20:37 -04:00
|
|
|
a new vec in `fill_vec`, and fill it with the expected values"""
|
2020-12-07 09:37:19 -05:00
|
|
|
|
2021-05-17 08:10:40 -04:00
|
|
|
[[exercises]]
|
|
|
|
name = "move_semantics5"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/06_move_semantics/move_semantics5.rs"
|
2023-08-26 18:46:48 -04:00
|
|
|
mode = "test"
|
2021-05-17 08:10:40 -04:00
|
|
|
hint = """
|
|
|
|
Carefully reason about the range in which each mutable reference is in
|
2023-09-28 18:39:51 -04:00
|
|
|
scope. Does it help to update the value of referent (`x`) immediately after
|
2021-05-22 23:09:58 -04:00
|
|
|
the mutable reference is taken? Read more about 'Mutable References'
|
2023-09-28 18:39:51 -04:00
|
|
|
in the book's section 'References and Borrowing':
|
2021-05-22 23:09:58 -04:00
|
|
|
https://doc.rust-lang.org/book/ch04-02-references-and-borrowing.html#mutable-references.
|
2021-07-29 06:37:15 -04:00
|
|
|
"""
|
2021-05-17 08:10:40 -04:00
|
|
|
|
2022-03-29 09:02:35 -04:00
|
|
|
[[exercises]]
|
|
|
|
name = "move_semantics6"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/06_move_semantics/move_semantics6.rs"
|
2022-03-29 09:02:35 -04:00
|
|
|
mode = "compile"
|
|
|
|
hint = """
|
|
|
|
To find the answer, you can consult the book section "References and Borrowing":
|
|
|
|
https://doc.rust-lang.org/stable/book/ch04-02-references-and-borrowing.html
|
2023-09-28 18:39:51 -04:00
|
|
|
|
|
|
|
The first problem is that `get_char` is taking ownership of the string. So
|
|
|
|
`data` is moved and can't be used for `string_uppercase`. `data` is moved to
|
|
|
|
`get_char` first, meaning that `string_uppercase` cannot manipulate the data.
|
|
|
|
|
|
|
|
Once you've fixed that, `string_uppercase`'s function signature will also need
|
|
|
|
to be adjusted.
|
|
|
|
|
2022-03-29 09:02:35 -04:00
|
|
|
Can you figure out how?
|
|
|
|
|
|
|
|
Another hint: it has to do with the `&` character."""
|
|
|
|
|
2019-05-25 07:39:58 -04:00
|
|
|
# STRUCTS
|
|
|
|
|
|
|
|
[[exercises]]
|
2019-11-11 09:46:32 -05:00
|
|
|
name = "structs1"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/07_structs/structs1.rs"
|
2019-05-25 07:39:58 -04:00
|
|
|
mode = "test"
|
2020-04-16 10:21:36 -04:00
|
|
|
hint = """
|
2023-09-28 18:39:51 -04:00
|
|
|
Rust has more than one type of struct. Three actually, all variants are used to
|
|
|
|
package related data together.
|
|
|
|
|
|
|
|
There are normal (or classic) structs. These are named collections of related
|
|
|
|
data stored in fields.
|
|
|
|
|
2020-11-08 04:31:45 -05:00
|
|
|
Tuple structs are basically just named tuples.
|
2023-09-28 18:39:51 -04:00
|
|
|
|
|
|
|
Finally, Unit-like structs. These don't have any fields and are useful for
|
|
|
|
generics.
|
2020-04-16 10:21:36 -04:00
|
|
|
|
2020-11-08 04:31:45 -05:00
|
|
|
In this exercise you need to complete and implement one of each kind.
|
2023-09-28 18:39:51 -04:00
|
|
|
Read more about structs in The Book:
|
|
|
|
https://doc.rust-lang.org/book/ch05-01-defining-structs.html"""
|
2019-05-25 07:39:58 -04:00
|
|
|
|
2019-10-21 08:23:06 -04:00
|
|
|
[[exercises]]
|
2019-11-11 09:46:32 -05:00
|
|
|
name = "structs2"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/07_structs/structs2.rs"
|
2019-10-21 08:23:06 -04:00
|
|
|
mode = "test"
|
2020-04-16 10:21:36 -04:00
|
|
|
hint = """
|
2023-09-28 18:39:51 -04:00
|
|
|
Creating instances of structs is easy, all you need to do is assign some values
|
|
|
|
to its fields.
|
|
|
|
|
2021-03-12 09:38:28 -05:00
|
|
|
There are however some shortcuts that can be taken when instantiating structs.
|
2023-09-28 18:39:51 -04:00
|
|
|
Have a look in The Book, to find out more:
|
|
|
|
https://doc.rust-lang.org/stable/book/ch05-01-defining-structs.html#creating-instances-from-other-instances-with-struct-update-syntax"""
|
2019-10-21 08:23:06 -04:00
|
|
|
|
2020-04-27 14:17:26 -04:00
|
|
|
[[exercises]]
|
|
|
|
name = "structs3"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/07_structs/structs3.rs"
|
2020-04-27 14:17:26 -04:00
|
|
|
mode = "test"
|
|
|
|
hint = """
|
2023-09-28 18:39:51 -04:00
|
|
|
For `is_international`: What makes a package international? Seems related to
|
|
|
|
the places it goes through right?
|
2020-04-27 14:17:26 -04:00
|
|
|
|
2023-09-28 18:39:51 -04:00
|
|
|
For `get_fees`: This method takes an additional argument, is there a field in
|
|
|
|
the `Package` struct that this relates to?
|
2020-04-27 14:17:26 -04:00
|
|
|
|
2023-09-28 18:39:51 -04:00
|
|
|
Have a look in The Book, to find out more about method implementations:
|
|
|
|
https://doc.rust-lang.org/book/ch05-03-method-syntax.html"""
|
2020-04-27 14:17:26 -04:00
|
|
|
|
2019-10-28 23:49:49 -04:00
|
|
|
# ENUMS
|
|
|
|
|
|
|
|
[[exercises]]
|
2019-11-11 09:46:32 -05:00
|
|
|
name = "enums1"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/08_enums/enums1.rs"
|
2019-10-28 23:49:49 -04:00
|
|
|
mode = "compile"
|
2022-07-14 06:11:38 -04:00
|
|
|
hint = "No hints this time ;)"
|
2019-10-28 23:49:49 -04:00
|
|
|
|
|
|
|
[[exercises]]
|
2019-11-11 09:46:32 -05:00
|
|
|
name = "enums2"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/08_enums/enums2.rs"
|
2019-10-28 23:49:49 -04:00
|
|
|
mode = "compile"
|
2019-11-11 10:51:38 -05:00
|
|
|
hint = """
|
2022-07-11 07:12:47 -04:00
|
|
|
You can create enumerations that have different variants with different types
|
2019-11-11 10:51:38 -05:00
|
|
|
such as no data, anonymous structs, a single string, tuples, ...etc"""
|
2019-10-28 23:49:49 -04:00
|
|
|
|
|
|
|
[[exercises]]
|
2019-11-11 09:46:32 -05:00
|
|
|
name = "enums3"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/08_enums/enums3.rs"
|
2019-10-28 23:49:49 -04:00
|
|
|
mode = "test"
|
2022-01-09 05:30:31 -05:00
|
|
|
hint = """
|
|
|
|
As a first step, you can define enums to compile this code without errors.
|
2023-09-28 18:39:51 -04:00
|
|
|
|
|
|
|
And then create a match expression in `process()`.
|
|
|
|
|
|
|
|
Note that you need to deconstruct some message variants in the match expression
|
|
|
|
to get value in the variant."""
|
2019-10-28 23:49:49 -04:00
|
|
|
|
2022-07-14 06:18:21 -04:00
|
|
|
# STRINGS
|
|
|
|
|
|
|
|
[[exercises]]
|
|
|
|
name = "strings1"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/09_strings/strings1.rs"
|
2022-07-14 06:18:21 -04:00
|
|
|
mode = "compile"
|
|
|
|
hint = """
|
2023-09-28 18:39:51 -04:00
|
|
|
The `current_favorite_color` function is currently returning a string slice
|
|
|
|
with the `'static` lifetime. We know this because the data of the string lives
|
|
|
|
in our code itself -- it doesn't come from a file or user input or another
|
|
|
|
program -- so it will live as long as our program lives.
|
|
|
|
|
|
|
|
But it is still a string slice. There's one way to create a `String` by
|
|
|
|
converting a string slice covered in the Strings chapter of the book, and
|
|
|
|
another way that uses the `From` trait."""
|
2022-07-14 06:18:21 -04:00
|
|
|
|
|
|
|
[[exercises]]
|
|
|
|
name = "strings2"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/09_strings/strings2.rs"
|
2022-07-14 06:18:21 -04:00
|
|
|
mode = "compile"
|
|
|
|
hint = """
|
2023-09-28 18:39:51 -04:00
|
|
|
Yes, it would be really easy to fix this by just changing the value bound to
|
|
|
|
`word` to be a string slice instead of a `String`, wouldn't it?? There is a way
|
|
|
|
to add one character to the `if` statement, though, that will coerce the
|
|
|
|
`String` into a string slice.
|
2023-03-10 11:58:03 -05:00
|
|
|
|
2023-09-28 18:39:51 -04:00
|
|
|
Side note: If you're interested in learning about how this kind of reference
|
|
|
|
conversion works, you can jump ahead in the book and read this part in the
|
|
|
|
smart pointers chapter:
|
|
|
|
https://doc.rust-lang.org/stable/book/ch15-02-deref.html#implicit-deref-coercions-with-functions-and-methods"""
|
2022-07-14 06:18:21 -04:00
|
|
|
|
2022-07-14 06:31:28 -04:00
|
|
|
[[exercises]]
|
|
|
|
name = "strings3"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/09_strings/strings3.rs"
|
2022-07-14 06:31:28 -04:00
|
|
|
mode = "test"
|
|
|
|
hint = """
|
2023-09-28 18:39:51 -04:00
|
|
|
There's tons of useful standard library functions for strings. Let's try and use some of them:
|
|
|
|
https://doc.rust-lang.org/std/string/struct.String.html#method.trim
|
2022-07-14 06:31:28 -04:00
|
|
|
|
2023-09-28 18:39:51 -04:00
|
|
|
For the `compose_me` method: You can either use the `format!` macro, or convert
|
|
|
|
the string slice into an owned string, which you can then freely extend."""
|
2022-07-14 06:31:28 -04:00
|
|
|
|
2022-07-14 07:01:40 -04:00
|
|
|
[[exercises]]
|
|
|
|
name = "strings4"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/09_strings/strings4.rs"
|
2022-07-14 07:01:40 -04:00
|
|
|
mode = "compile"
|
|
|
|
hint = "No hints this time ;)"
|
|
|
|
|
2019-03-06 15:47:00 -05:00
|
|
|
# MODULES
|
|
|
|
|
|
|
|
[[exercises]]
|
2019-11-11 09:46:32 -05:00
|
|
|
name = "modules1"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/10_modules/modules1.rs"
|
2019-03-06 15:47:00 -05:00
|
|
|
mode = "compile"
|
2019-11-11 10:51:38 -05:00
|
|
|
hint = """
|
|
|
|
Everything is private in Rust by default-- but there's a keyword we can use
|
|
|
|
to make something public! The compiler error should point to the thing that
|
|
|
|
needs to be public."""
|
2019-03-06 15:47:00 -05:00
|
|
|
|
|
|
|
[[exercises]]
|
2019-11-11 09:46:32 -05:00
|
|
|
name = "modules2"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/10_modules/modules2.rs"
|
2019-03-06 15:47:00 -05:00
|
|
|
mode = "compile"
|
2019-11-11 10:51:38 -05:00
|
|
|
hint = """
|
2022-11-11 10:12:09 -05:00
|
|
|
The delicious_snacks module is trying to present an external interface that is
|
2021-09-03 04:41:12 -04:00
|
|
|
different than its internal structure (the `fruits` and `veggies` modules and
|
2021-10-02 09:59:23 -04:00
|
|
|
associated constants). Complete the `use` statements to fit the uses in main and
|
2023-04-21 11:51:52 -04:00
|
|
|
find the one keyword missing for both constants.
|
2023-09-28 18:39:51 -04:00
|
|
|
|
2023-04-21 11:51:52 -04:00
|
|
|
Learn more at https://doc.rust-lang.org/book/ch07-04-bringing-paths-into-scope-with-the-use-keyword.html#re-exporting-names-with-pub-use"""
|
2021-09-03 04:41:12 -04:00
|
|
|
|
|
|
|
[[exercises]]
|
|
|
|
name = "modules3"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/10_modules/modules3.rs"
|
2021-09-03 04:41:12 -04:00
|
|
|
mode = "compile"
|
|
|
|
hint = """
|
2023-09-28 18:39:51 -04:00
|
|
|
`UNIX_EPOCH` and `SystemTime` are declared in the `std::time` module. Add a
|
|
|
|
`use` statement for these two to bring them into scope. You can use nested
|
|
|
|
paths or the glob operator to bring these two in using only one line."""
|
2019-03-06 15:47:00 -05:00
|
|
|
|
2022-07-12 09:18:05 -04:00
|
|
|
# HASHMAPS
|
2020-12-12 13:21:23 -05:00
|
|
|
|
|
|
|
[[exercises]]
|
2022-07-12 09:18:05 -04:00
|
|
|
name = "hashmaps1"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/11_hashmaps/hashmaps1.rs"
|
2020-12-12 13:21:23 -05:00
|
|
|
mode = "test"
|
|
|
|
hint = """
|
|
|
|
Hint 1: Take a look at the return type of the function to figure out
|
2023-09-28 18:39:51 -04:00
|
|
|
the type for the `basket`.
|
|
|
|
|
2020-12-12 13:21:23 -05:00
|
|
|
Hint 2: Number of fruits should be at least 5. And you have to put
|
2023-09-28 18:39:51 -04:00
|
|
|
at least three different types of fruits.
|
2020-12-12 13:21:23 -05:00
|
|
|
"""
|
|
|
|
|
|
|
|
[[exercises]]
|
2022-07-12 09:18:05 -04:00
|
|
|
name = "hashmaps2"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/11_hashmaps/hashmaps2.rs"
|
2020-12-12 13:21:23 -05:00
|
|
|
mode = "test"
|
|
|
|
hint = """
|
|
|
|
Use the `entry()` and `or_insert()` methods of `HashMap` to achieve this.
|
|
|
|
Learn more at https://doc.rust-lang.org/stable/book/ch08-03-hash-maps.html#only-inserting-a-value-if-the-key-has-no-value
|
|
|
|
"""
|
|
|
|
|
2021-06-04 06:39:12 -04:00
|
|
|
[[exercises]]
|
|
|
|
name = "hashmaps3"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/11_hashmaps/hashmaps3.rs"
|
2021-06-04 06:39:12 -04:00
|
|
|
mode = "test"
|
|
|
|
hint = """
|
2023-09-28 18:39:51 -04:00
|
|
|
Hint 1: Use the `entry()` and `or_insert()` methods of `HashMap` to insert
|
|
|
|
entries corresponding to each team in the scores table.
|
|
|
|
|
2021-06-04 06:39:12 -04:00
|
|
|
Learn more at https://doc.rust-lang.org/stable/book/ch08-03-hash-maps.html#only-inserting-a-value-if-the-key-has-no-value
|
2023-09-28 18:39:51 -04:00
|
|
|
|
|
|
|
Hint 2: If there is already an entry for a given key, the value returned by
|
|
|
|
`entry()` can be updated based on the existing value.
|
|
|
|
|
2021-06-04 06:39:12 -04:00
|
|
|
Learn more at https://doc.rust-lang.org/book/ch08-03-hash-maps.html#updating-a-value-based-on-the-old-value
|
|
|
|
"""
|
|
|
|
|
2022-07-14 07:01:40 -04:00
|
|
|
# QUIZ 2
|
2019-03-06 15:47:00 -05:00
|
|
|
|
|
|
|
[[exercises]]
|
2020-12-07 09:37:19 -05:00
|
|
|
name = "quiz2"
|
|
|
|
path = "exercises/quiz2.rs"
|
2022-07-14 07:16:32 -04:00
|
|
|
mode = "test"
|
2020-12-07 09:37:19 -05:00
|
|
|
hint = "No hints this time ;)"
|
2019-03-06 15:47:00 -05:00
|
|
|
|
2022-07-14 11:34:50 -04:00
|
|
|
# OPTIONS
|
|
|
|
|
|
|
|
[[exercises]]
|
|
|
|
name = "options1"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/12_options/options1.rs"
|
2022-07-14 11:53:42 -04:00
|
|
|
mode = "test"
|
2022-07-14 11:34:50 -04:00
|
|
|
hint = """
|
2023-09-28 18:39:51 -04:00
|
|
|
Options can have a `Some` value, with an inner value, or a `None` value,
|
|
|
|
without an inner value.
|
|
|
|
|
|
|
|
There's multiple ways to get at the inner value, you can use `unwrap`, or
|
|
|
|
pattern match. Unwrapping is the easiest, but how do you do it safely so that
|
|
|
|
it doesn't panic in your face later?"""
|
2022-07-14 11:34:50 -04:00
|
|
|
|
|
|
|
[[exercises]]
|
|
|
|
name = "options2"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/12_options/options2.rs"
|
2022-08-17 06:50:34 -04:00
|
|
|
mode = "test"
|
2022-07-14 11:34:50 -04:00
|
|
|
hint = """
|
2023-09-28 18:39:51 -04:00
|
|
|
Check out:
|
2022-07-14 11:34:50 -04:00
|
|
|
|
2023-09-28 18:39:51 -04:00
|
|
|
- https://doc.rust-lang.org/rust-by-example/flow_control/if_let.html
|
|
|
|
- https://doc.rust-lang.org/rust-by-example/flow_control/while_let.html
|
|
|
|
|
|
|
|
Remember that `Option`s can be stacked in `if let` and `while let`.
|
|
|
|
|
|
|
|
For example: `Some(Some(variable)) = variable2`
|
|
|
|
|
|
|
|
Also see `Option::flatten`
|
2022-07-14 11:34:50 -04:00
|
|
|
"""
|
|
|
|
|
|
|
|
[[exercises]]
|
|
|
|
name = "options3"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/12_options/options3.rs"
|
2022-07-14 11:34:50 -04:00
|
|
|
mode = "compile"
|
|
|
|
hint = """
|
2023-09-28 18:39:51 -04:00
|
|
|
The compiler says a partial move happened in the `match` statement. How can
|
|
|
|
this be avoided? The compiler shows the correction needed.
|
|
|
|
|
|
|
|
After making the correction as suggested by the compiler, do read:
|
|
|
|
https://doc.rust-lang.org/std/keyword.ref.html"""
|
2022-07-14 11:34:50 -04:00
|
|
|
|
2019-03-06 15:47:00 -05:00
|
|
|
# ERROR HANDLING
|
|
|
|
|
|
|
|
[[exercises]]
|
2019-11-11 09:46:32 -05:00
|
|
|
name = "errors1"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/13_error_handling/errors1.rs"
|
2019-03-06 15:47:00 -05:00
|
|
|
mode = "test"
|
2019-11-11 10:51:38 -05:00
|
|
|
hint = """
|
2023-10-13 15:28:14 -04:00
|
|
|
`Ok` and `Err` are the two variants of `Result`, so what the tests are saying
|
2023-09-28 18:39:51 -04:00
|
|
|
is that `generate_nametag_text` should return a `Result` instead of an `Option`.
|
2019-11-11 10:51:38 -05:00
|
|
|
|
|
|
|
To make this change, you'll need to:
|
2023-09-28 18:39:51 -04:00
|
|
|
- update the return type in the function signature to be a `Result<String,
|
|
|
|
String>` that could be the variants `Ok(String)` and `Err(String)`
|
|
|
|
- change the body of the function to return `Ok(stuff)` where it currently
|
|
|
|
returns `Some(stuff)`
|
|
|
|
- change the body of the function to return `Err(error message)` where it
|
|
|
|
currently returns `None`"""
|
2019-03-06 15:47:00 -05:00
|
|
|
|
|
|
|
[[exercises]]
|
2019-11-11 09:46:32 -05:00
|
|
|
name = "errors2"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/13_error_handling/errors2.rs"
|
2019-03-06 15:47:00 -05:00
|
|
|
mode = "test"
|
2019-11-11 10:51:38 -05:00
|
|
|
hint = """
|
|
|
|
One way to handle this is using a `match` statement on
|
|
|
|
`item_quantity.parse::<i32>()` where the cases are `Ok(something)` and
|
2023-09-28 18:39:51 -04:00
|
|
|
`Err(something)`.
|
|
|
|
|
|
|
|
This pattern is very common in Rust, though, so there's a `?` operator that
|
|
|
|
does pretty much what you would make that match statement do for you!
|
|
|
|
|
|
|
|
Take a look at this section of the 'Error Handling' chapter:
|
2019-11-11 10:51:38 -05:00
|
|
|
https://doc.rust-lang.org/book/ch09-02-recoverable-errors-with-result.html#a-shortcut-for-propagating-errors-the--operator
|
|
|
|
and give it a try!"""
|
2019-03-06 15:47:00 -05:00
|
|
|
|
|
|
|
[[exercises]]
|
2019-11-11 09:46:32 -05:00
|
|
|
name = "errors3"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/13_error_handling/errors3.rs"
|
2021-03-12 14:04:29 -05:00
|
|
|
mode = "compile"
|
2019-11-11 10:51:38 -05:00
|
|
|
hint = """
|
2023-09-28 18:39:51 -04:00
|
|
|
If other functions can return a `Result`, why shouldn't `main`? It's a fairly
|
|
|
|
common convention to return something like `Result<(), ErrorType>` from your
|
|
|
|
main function.
|
|
|
|
|
|
|
|
The unit (`()`) type is there because nothing is really needed in terms of
|
|
|
|
positive results."""
|
2019-03-06 15:47:00 -05:00
|
|
|
|
2021-06-06 21:14:29 -04:00
|
|
|
[[exercises]]
|
|
|
|
name = "errors4"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/13_error_handling/errors4.rs"
|
2021-06-06 21:14:29 -04:00
|
|
|
mode = "test"
|
|
|
|
hint = """
|
2023-09-28 18:39:51 -04:00
|
|
|
`PositiveNonzeroInteger::new` is always creating a new instance and returning
|
|
|
|
an `Ok` result.
|
|
|
|
|
|
|
|
It should be doing some checking, returning an `Err` result if those checks
|
|
|
|
fail, and only returning an `Ok` result if those checks determine that
|
|
|
|
everything is... okay :)"""
|
2021-06-06 21:14:29 -04:00
|
|
|
|
2019-03-06 15:47:00 -05:00
|
|
|
[[exercises]]
|
2021-06-07 00:05:01 -04:00
|
|
|
name = "errors5"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/13_error_handling/errors5.rs"
|
2021-06-07 00:05:01 -04:00
|
|
|
mode = "compile"
|
2019-11-11 10:51:38 -05:00
|
|
|
hint = """
|
2023-09-28 18:39:51 -04:00
|
|
|
There are two different possible `Result` types produced within `main()`, which
|
|
|
|
are propagated using `?` operators. How do we declare a return type from
|
|
|
|
`main()` that allows both?
|
2022-06-15 09:40:30 -04:00
|
|
|
|
2023-09-28 18:39:51 -04:00
|
|
|
Under the hood, the `?` operator calls `From::from` on the error value to
|
|
|
|
convert it to a boxed trait object, a `Box<dyn error::Error>`. This boxed trait
|
|
|
|
object is polymorphic, and since all errors implement the `error::Error` trait,
|
|
|
|
we can capture lots of different errors in one "Box" object.
|
2022-06-15 09:40:30 -04:00
|
|
|
|
2019-11-11 10:51:38 -05:00
|
|
|
Check out this section of the book:
|
|
|
|
https://doc.rust-lang.org/book/ch09-02-recoverable-errors-with-result.html#a-shortcut-for-propagating-errors-the--operator
|
|
|
|
|
2021-06-07 00:05:01 -04:00
|
|
|
Read more about boxing errors:
|
|
|
|
https://doc.rust-lang.org/stable/rust-by-example/error/multiple_error_types/boxing_errors.html
|
2019-11-11 10:51:38 -05:00
|
|
|
|
2021-06-07 00:05:01 -04:00
|
|
|
Read more about using the `?` operator with boxed errors:
|
|
|
|
https://doc.rust-lang.org/stable/rust-by-example/error/multiple_error_types/reenter_question_mark.html
|
|
|
|
"""
|
|
|
|
|
|
|
|
[[exercises]]
|
|
|
|
name = "errors6"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/13_error_handling/errors6.rs"
|
2021-06-07 00:05:01 -04:00
|
|
|
mode = "test"
|
|
|
|
hint = """
|
|
|
|
This exercise uses a completed version of `PositiveNonzeroInteger` from
|
2021-06-09 19:13:57 -04:00
|
|
|
errors4.
|
2019-11-11 10:51:38 -05:00
|
|
|
|
2023-09-28 18:39:51 -04:00
|
|
|
Below the line that `TODO` asks you to change, there is an example of using
|
2021-06-09 19:13:57 -04:00
|
|
|
the `map_err()` method on a `Result` to transform one type of error into
|
|
|
|
another. Try using something similar on the `Result` from `parse()`. You
|
|
|
|
might use the `?` operator to return early from the function, or you might
|
|
|
|
use a `match` expression, or maybe there's another way!
|
2019-11-11 10:51:38 -05:00
|
|
|
|
2021-06-09 19:13:57 -04:00
|
|
|
You can create another function inside `impl ParsePosNonzeroError` to use
|
|
|
|
with `map_err()`.
|
|
|
|
|
|
|
|
Read more about `map_err()` in the `std::result` documentation:
|
|
|
|
https://doc.rust-lang.org/std/result/enum.Result.html#method.map_err"""
|
2019-03-06 15:47:00 -05:00
|
|
|
|
2020-12-07 09:37:19 -05:00
|
|
|
# Generics
|
|
|
|
|
|
|
|
[[exercises]]
|
|
|
|
name = "generics1"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/14_generics/generics1.rs"
|
2020-12-07 09:37:19 -05:00
|
|
|
mode = "compile"
|
|
|
|
hint = """
|
2023-09-28 18:39:51 -04:00
|
|
|
Vectors in Rust make use of generics to create dynamically sized arrays of any
|
|
|
|
type.
|
|
|
|
|
2020-12-07 09:37:19 -05:00
|
|
|
You need to tell the compiler what type we are pushing onto this vector."""
|
|
|
|
|
|
|
|
[[exercises]]
|
|
|
|
name = "generics2"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/14_generics/generics2.rs"
|
2020-12-07 09:37:19 -05:00
|
|
|
mode = "test"
|
|
|
|
hint = """
|
2023-09-28 18:39:51 -04:00
|
|
|
Currently we are wrapping only values of type `u32`.
|
|
|
|
|
2020-12-07 09:37:19 -05:00
|
|
|
Maybe we could update the explicit references to this data type somehow?
|
|
|
|
|
|
|
|
If you are still stuck https://doc.rust-lang.org/stable/book/ch10-01-syntax.html#in-method-definitions
|
|
|
|
"""
|
|
|
|
|
|
|
|
# TRAITS
|
2020-02-14 09:25:03 -05:00
|
|
|
|
|
|
|
[[exercises]]
|
2020-12-07 09:37:19 -05:00
|
|
|
name = "traits1"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/15_traits/traits1.rs"
|
2020-12-07 09:37:19 -05:00
|
|
|
mode = "test"
|
2020-02-14 09:25:03 -05:00
|
|
|
hint = """
|
2020-12-07 09:37:19 -05:00
|
|
|
A discussion about Traits in Rust can be found at:
|
|
|
|
https://doc.rust-lang.org/book/ch10-02-traits.html
|
|
|
|
"""
|
2020-02-14 09:25:03 -05:00
|
|
|
|
|
|
|
[[exercises]]
|
2020-12-07 09:37:19 -05:00
|
|
|
name = "traits2"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/15_traits/traits2.rs"
|
2020-12-07 09:37:19 -05:00
|
|
|
mode = "test"
|
2020-02-14 09:25:03 -05:00
|
|
|
hint = """
|
2023-09-28 18:39:51 -04:00
|
|
|
Notice how the trait takes ownership of `self`, and returns `Self`.
|
|
|
|
|
2022-07-14 12:14:41 -04:00
|
|
|
Try mutating the incoming string vector. Have a look at the tests to see
|
|
|
|
what the result should look like!
|
2020-12-07 09:37:19 -05:00
|
|
|
|
|
|
|
Vectors provide suitable methods for adding an element at the end. See
|
|
|
|
the documentation at: https://doc.rust-lang.org/std/vec/struct.Vec.html"""
|
|
|
|
|
2022-02-25 11:40:38 -05:00
|
|
|
[[exercises]]
|
|
|
|
name = "traits3"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/15_traits/traits3.rs"
|
2022-02-25 11:40:38 -05:00
|
|
|
mode = "test"
|
|
|
|
hint = """
|
|
|
|
Traits can have a default implementation for functions. Structs that implement
|
|
|
|
the trait can then use the default version of these functions if they choose not
|
2023-11-05 09:30:47 -05:00
|
|
|
to implement the function themselves.
|
2022-02-25 11:40:38 -05:00
|
|
|
|
|
|
|
See the documentation at: https://doc.rust-lang.org/book/ch10-02-traits.html#default-implementations
|
|
|
|
"""
|
|
|
|
|
2022-02-25 11:41:10 -05:00
|
|
|
[[exercises]]
|
|
|
|
name = "traits4"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/15_traits/traits4.rs"
|
2022-02-25 11:41:10 -05:00
|
|
|
mode = "test"
|
|
|
|
hint = """
|
2023-09-28 18:39:51 -04:00
|
|
|
Instead of using concrete types as parameters you can use traits. Try replacing
|
|
|
|
the '??' with 'impl <what goes here?>'
|
2022-02-25 11:41:10 -05:00
|
|
|
|
|
|
|
See the documentation at: https://doc.rust-lang.org/book/ch10-02-traits.html#traits-as-parameters
|
|
|
|
"""
|
|
|
|
|
2022-02-25 11:41:36 -05:00
|
|
|
[[exercises]]
|
|
|
|
name = "traits5"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/15_traits/traits5.rs"
|
2022-02-25 11:41:36 -05:00
|
|
|
mode = "compile"
|
|
|
|
hint = """
|
2023-09-28 18:39:51 -04:00
|
|
|
To ensure a parameter implements multiple traits use the '+ syntax'. Try
|
|
|
|
replacing the '??' with 'impl <> + <>'.
|
2022-02-25 11:41:36 -05:00
|
|
|
|
|
|
|
See the documentation at: https://doc.rust-lang.org/book/ch10-02-traits.html#specifying-multiple-trait-bounds-with-the--syntax
|
|
|
|
"""
|
|
|
|
|
2022-07-14 12:11:18 -04:00
|
|
|
# QUIZ 3
|
|
|
|
|
|
|
|
[[exercises]]
|
|
|
|
name = "quiz3"
|
|
|
|
path = "exercises/quiz3.rs"
|
|
|
|
mode = "test"
|
|
|
|
hint = """
|
2023-09-28 18:39:51 -04:00
|
|
|
To find the best solution to this challenge you're going to need to think back
|
|
|
|
to your knowledge of traits, specifically 'Trait Bound Syntax'
|
|
|
|
|
|
|
|
You may also need this: `use std::fmt::Display;`."""
|
2022-07-14 12:11:18 -04:00
|
|
|
|
2023-04-02 02:55:24 -04:00
|
|
|
# LIFETIMES
|
|
|
|
|
|
|
|
[[exercises]]
|
|
|
|
name = "lifetimes1"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/16_lifetimes/lifetimes1.rs"
|
2023-04-02 02:55:24 -04:00
|
|
|
mode = "compile"
|
|
|
|
hint = """
|
|
|
|
Let the compiler guide you. Also take a look at the book if you need help:
|
|
|
|
https://doc.rust-lang.org/book/ch10-03-lifetime-syntax.html"""
|
|
|
|
|
|
|
|
[[exercises]]
|
|
|
|
name = "lifetimes2"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/16_lifetimes/lifetimes2.rs"
|
2023-04-02 02:55:24 -04:00
|
|
|
mode = "compile"
|
|
|
|
hint = """
|
2023-09-28 18:39:51 -04:00
|
|
|
Remember that the generic lifetime `'a` will get the concrete lifetime that is
|
|
|
|
equal to the smaller of the lifetimes of `x` and `y`.
|
|
|
|
|
|
|
|
You can take at least two paths to achieve the desired result while keeping the
|
|
|
|
inner block:
|
|
|
|
1. Move the `string2` declaration to make it live as long as `string1` (how is
|
|
|
|
`result` declared?)
|
|
|
|
2. Move `println!` into the inner block"""
|
2023-04-02 02:55:24 -04:00
|
|
|
|
|
|
|
[[exercises]]
|
|
|
|
name = "lifetimes3"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/16_lifetimes/lifetimes3.rs"
|
2023-04-02 02:55:24 -04:00
|
|
|
mode = "compile"
|
|
|
|
hint = """
|
2023-09-28 18:39:51 -04:00
|
|
|
If you use a lifetime annotation in a struct's fields, where else does it need
|
|
|
|
to be added?"""
|
2023-04-02 02:55:24 -04:00
|
|
|
|
2020-12-07 09:37:19 -05:00
|
|
|
# TESTS
|
|
|
|
|
|
|
|
[[exercises]]
|
|
|
|
name = "tests1"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/17_tests/tests1.rs"
|
2020-12-07 09:37:19 -05:00
|
|
|
mode = "test"
|
|
|
|
hint = """
|
2023-09-28 18:39:51 -04:00
|
|
|
You don't even need to write any code to test -- you can just test values and
|
|
|
|
run that, even though you wouldn't do that in real life. :)
|
|
|
|
|
|
|
|
`assert!` is a macro that needs an argument. Depending on the value of the
|
|
|
|
argument, `assert!` will do nothing (in which case the test will pass) or
|
|
|
|
`assert!` will panic (in which case the test will fail).
|
|
|
|
|
|
|
|
So try giving different values to `assert!` and see which ones compile, which
|
|
|
|
ones pass, and which ones fail :)"""
|
2020-12-07 09:37:19 -05:00
|
|
|
|
|
|
|
[[exercises]]
|
|
|
|
name = "tests2"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/17_tests/tests2.rs"
|
2020-12-07 09:37:19 -05:00
|
|
|
mode = "test"
|
|
|
|
hint = """
|
2023-09-28 18:39:51 -04:00
|
|
|
Like the previous exercise, you don't need to write any code to get this test
|
|
|
|
to compile and run.
|
|
|
|
|
|
|
|
`assert_eq!` is a macro that takes two arguments and compares them. Try giving
|
|
|
|
it two values that are equal! Try giving it two arguments that are different!
|
|
|
|
Try giving it two values that are of different types! Try switching which
|
|
|
|
argument comes first and which comes second!"""
|
2020-12-07 09:37:19 -05:00
|
|
|
|
|
|
|
[[exercises]]
|
|
|
|
name = "tests3"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/17_tests/tests3.rs"
|
2020-12-07 09:37:19 -05:00
|
|
|
mode = "test"
|
|
|
|
hint = """
|
2023-09-28 18:39:51 -04:00
|
|
|
You can call a function right where you're passing arguments to `assert!`. So
|
|
|
|
you could do something like `assert!(having_fun())`.
|
|
|
|
|
|
|
|
If you want to check that you indeed get `false`, you can negate the result of
|
|
|
|
what you're doing using `!`, like `assert!(!having_fun())`."""
|
2020-12-07 09:37:19 -05:00
|
|
|
|
2023-04-05 02:18:51 -04:00
|
|
|
[[exercises]]
|
|
|
|
name = "tests4"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/17_tests/tests4.rs"
|
2023-04-05 02:18:51 -04:00
|
|
|
mode = "test"
|
|
|
|
hint = """
|
|
|
|
We expect method `Rectangle::new()` to panic for negative values.
|
2023-09-28 18:39:51 -04:00
|
|
|
|
2023-04-05 07:09:13 -04:00
|
|
|
To handle that you need to add a special attribute to the test function.
|
2023-09-28 18:39:51 -04:00
|
|
|
|
2023-04-05 07:09:13 -04:00
|
|
|
You can refer to the docs:
|
|
|
|
https://doc.rust-lang.org/stable/book/ch11-01-writing-tests.html#checking-for-panics-with-should_panic"""
|
2023-04-05 02:18:51 -04:00
|
|
|
|
2019-03-13 10:29:02 -04:00
|
|
|
# STANDARD LIBRARY TYPES
|
|
|
|
|
2020-12-12 13:21:23 -05:00
|
|
|
[[exercises]]
|
|
|
|
name = "iterators1"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/18_iterators/iterators1.rs"
|
2023-08-26 19:06:01 -04:00
|
|
|
mode = "test"
|
2020-12-12 13:21:23 -05:00
|
|
|
hint = """
|
|
|
|
Step 1:
|
2023-09-28 18:39:51 -04:00
|
|
|
|
|
|
|
We need to apply something to the collection `my_fav_fruits` before we start to
|
|
|
|
go through it. What could that be? Take a look at the struct definition for a
|
|
|
|
vector for inspiration:
|
2023-01-10 13:53:21 -05:00
|
|
|
https://doc.rust-lang.org/std/vec/struct.Vec.html
|
2023-09-28 18:39:51 -04:00
|
|
|
|
2022-09-25 16:22:15 -04:00
|
|
|
Step 2 & step 3:
|
2023-09-28 18:39:51 -04:00
|
|
|
|
2020-12-12 13:21:23 -05:00
|
|
|
Very similar to the lines above and below. You've got this!
|
2023-09-28 18:39:51 -04:00
|
|
|
|
2022-09-25 16:22:15 -04:00
|
|
|
Step 4:
|
2023-09-28 18:39:51 -04:00
|
|
|
|
|
|
|
An iterator goes through all elements in a collection, but what if we've run
|
|
|
|
out of elements? What should we expect here? If you're stuck, take a look at
|
2020-12-12 13:21:23 -05:00
|
|
|
https://doc.rust-lang.org/std/iter/trait.Iterator.html for some ideas.
|
|
|
|
"""
|
|
|
|
|
2019-07-02 07:21:58 -04:00
|
|
|
[[exercises]]
|
2019-11-11 09:46:32 -05:00
|
|
|
name = "iterators2"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/18_iterators/iterators2.rs"
|
2019-07-02 07:21:58 -04:00
|
|
|
mode = "test"
|
2019-11-11 10:51:38 -05:00
|
|
|
hint = """
|
2023-09-28 18:39:51 -04:00
|
|
|
Step 1:
|
|
|
|
|
2021-02-11 21:24:32 -05:00
|
|
|
The variable `first` is a `char`. It needs to be capitalized and added to the
|
|
|
|
remaining characters in `c` in order to return the correct `String`.
|
2023-09-28 18:39:51 -04:00
|
|
|
|
2021-02-11 21:24:32 -05:00
|
|
|
The remaining characters in `c` can be viewed as a string slice using the
|
|
|
|
`as_str` method.
|
2023-09-28 18:39:51 -04:00
|
|
|
|
2021-02-11 21:24:32 -05:00
|
|
|
The documentation for `char` contains many useful methods.
|
2019-11-11 10:51:38 -05:00
|
|
|
https://doc.rust-lang.org/std/primitive.char.html
|
|
|
|
|
2023-09-28 18:39:51 -04:00
|
|
|
Step 2:
|
|
|
|
|
2021-02-11 21:24:32 -05:00
|
|
|
Create an iterator from the slice. Transform the iterated values by applying
|
2023-09-28 18:39:51 -04:00
|
|
|
the `capitalize_first` function. Remember to `collect` the iterator.
|
|
|
|
|
|
|
|
Step 3:
|
2019-11-11 10:51:38 -05:00
|
|
|
|
2023-09-28 18:39:51 -04:00
|
|
|
This is surprisingly similar to the previous solution. `collect` is very
|
|
|
|
powerful and very general. Rust just needs to know the desired type."""
|
2019-07-02 07:21:58 -04:00
|
|
|
|
2019-03-13 10:29:02 -04:00
|
|
|
[[exercises]]
|
2019-11-11 09:46:32 -05:00
|
|
|
name = "iterators3"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/18_iterators/iterators3.rs"
|
2019-03-13 10:29:02 -04:00
|
|
|
mode = "test"
|
2019-11-11 10:51:38 -05:00
|
|
|
hint = """
|
2023-09-28 18:39:51 -04:00
|
|
|
The `divide` function needs to return the correct error when even division is
|
|
|
|
not possible.
|
2019-11-11 10:51:38 -05:00
|
|
|
|
2023-09-28 18:39:51 -04:00
|
|
|
The `division_results` variable needs to be collected into a collection type.
|
2021-02-12 15:36:53 -05:00
|
|
|
|
2023-09-28 18:39:51 -04:00
|
|
|
The `result_with_list` function needs to return a single `Result` where the
|
|
|
|
success case is a vector of integers and the failure case is a `DivisionError`.
|
2021-02-12 15:36:53 -05:00
|
|
|
|
2023-09-28 18:39:51 -04:00
|
|
|
The `list_of_results` function needs to return a vector of results.
|
2021-06-29 06:03:18 -04:00
|
|
|
|
2023-09-28 18:39:51 -04:00
|
|
|
See https://doc.rust-lang.org/std/iter/trait.Iterator.html#method.collect for
|
|
|
|
how the `FromIterator` trait is used in `collect()`. This trait is REALLY
|
|
|
|
powerful! It can make the solution to this exercise infinitely easier."""
|
2019-03-13 10:29:02 -04:00
|
|
|
|
|
|
|
[[exercises]]
|
2019-11-11 09:46:32 -05:00
|
|
|
name = "iterators4"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/18_iterators/iterators4.rs"
|
2019-03-13 10:29:02 -04:00
|
|
|
mode = "test"
|
2019-11-11 10:51:38 -05:00
|
|
|
hint = """
|
2023-09-28 18:39:51 -04:00
|
|
|
In an imperative language, you might write a `for` loop that updates a mutable
|
|
|
|
variable. Or, you might write code utilizing recursion and a match clause. In
|
|
|
|
Rust you can take another functional approach, computing the factorial
|
|
|
|
elegantly with ranges and iterators.
|
2022-07-14 12:29:09 -04:00
|
|
|
|
|
|
|
Hint 2: Check out the `fold` and `rfold` methods!"""
|
2019-11-11 07:48:09 -05:00
|
|
|
|
2021-02-10 18:03:29 -05:00
|
|
|
[[exercises]]
|
|
|
|
name = "iterators5"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/18_iterators/iterators5.rs"
|
2021-02-10 18:03:29 -05:00
|
|
|
mode = "test"
|
|
|
|
hint = """
|
2023-09-28 18:39:51 -04:00
|
|
|
The documentation for the `std::iter::Iterator` trait contains numerous methods
|
2021-02-10 18:03:29 -05:00
|
|
|
that would be helpful here.
|
|
|
|
|
2023-09-28 18:39:51 -04:00
|
|
|
The `collection` variable in `count_collection_iterator` is a slice of
|
|
|
|
`HashMap`s. It needs to be converted into an iterator in order to use the
|
|
|
|
iterator methods.
|
2021-02-10 18:03:29 -05:00
|
|
|
|
2023-09-28 18:39:51 -04:00
|
|
|
The `fold` method can be useful in the `count_collection_iterator` function.
|
2021-06-06 18:39:13 -04:00
|
|
|
|
2023-09-28 18:39:51 -04:00
|
|
|
For a further challenge, consult the documentation for `Iterator` to find
|
|
|
|
a different method that could make your code more compact than using `fold`."""
|
2021-02-10 18:03:29 -05:00
|
|
|
|
2022-12-31 19:32:38 -05:00
|
|
|
# SMART POINTERS
|
|
|
|
|
|
|
|
[[exercises]]
|
|
|
|
name = "box1"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/19_smart_pointers/box1.rs"
|
2022-12-31 19:32:38 -05:00
|
|
|
mode = "test"
|
|
|
|
hint = """
|
2023-09-28 18:39:51 -04:00
|
|
|
Step 1:
|
|
|
|
|
|
|
|
The compiler's message should help: since we cannot store the value of the
|
|
|
|
actual type when working with recursive types, we need to store a reference
|
|
|
|
(pointer) to its value.
|
|
|
|
|
|
|
|
We should, therefore, place our `List` inside a `Box`. More details in the book
|
|
|
|
here: https://doc.rust-lang.org/book/ch15-01-box.html#enabling-recursive-types-with-boxes
|
|
|
|
|
|
|
|
Step 2:
|
|
|
|
|
|
|
|
Creating an empty list should be fairly straightforward (hint: peek at the
|
|
|
|
assertions).
|
|
|
|
|
|
|
|
For a non-empty list keep in mind that we want to use our `Cons` "list builder".
|
|
|
|
Although the current list is one of integers (`i32`), feel free to change the
|
|
|
|
definition and try other types!
|
2022-12-31 19:32:38 -05:00
|
|
|
"""
|
|
|
|
|
|
|
|
[[exercises]]
|
|
|
|
name = "rc1"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/19_smart_pointers/rc1.rs"
|
2023-08-26 19:06:01 -04:00
|
|
|
mode = "test"
|
2022-12-31 19:32:38 -05:00
|
|
|
hint = """
|
2023-09-28 18:39:51 -04:00
|
|
|
This is a straightforward exercise to use the `Rc<T>` type. Each `Planet` has
|
|
|
|
ownership of the `Sun`, and uses `Rc::clone()` to increment the reference count
|
|
|
|
of the `Sun`.
|
|
|
|
|
|
|
|
After using `drop()` to move the `Planet`s out of scope individually, the
|
|
|
|
reference count goes down.
|
|
|
|
|
|
|
|
In the end the `Sun` only has one reference again, to itself.
|
|
|
|
|
|
|
|
See more at: https://doc.rust-lang.org/book/ch15-04-rc.html
|
2022-12-31 19:32:38 -05:00
|
|
|
|
|
|
|
* Unfortunately Pluto is no longer considered a planet :(
|
|
|
|
"""
|
|
|
|
|
|
|
|
[[exercises]]
|
|
|
|
name = "arc1"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/19_smart_pointers/arc1.rs"
|
2022-12-31 19:32:38 -05:00
|
|
|
mode = "compile"
|
|
|
|
hint = """
|
|
|
|
Make `shared_numbers` be an `Arc` from the numbers vector. Then, in order
|
|
|
|
to avoid creating a copy of `numbers`, you'll need to create `child_numbers`
|
|
|
|
inside the loop but still in the main thread.
|
|
|
|
|
2023-09-28 18:39:51 -04:00
|
|
|
`child_numbers` should be a clone of the `Arc` of the numbers instead of a
|
2022-12-31 19:32:38 -05:00
|
|
|
thread-local copy of the numbers.
|
|
|
|
|
|
|
|
This is a simple exercise if you understand the underlying concepts, but if this
|
2023-09-28 18:39:51 -04:00
|
|
|
is too much of a struggle, consider reading through all of Chapter 16 in the
|
|
|
|
book:
|
2022-12-31 19:32:38 -05:00
|
|
|
https://doc.rust-lang.org/stable/book/ch16-00-concurrency.html
|
|
|
|
"""
|
|
|
|
|
|
|
|
[[exercises]]
|
|
|
|
name = "cow1"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/19_smart_pointers/cow1.rs"
|
2023-02-14 14:37:33 -05:00
|
|
|
mode = "test"
|
2022-12-31 19:32:38 -05:00
|
|
|
hint = """
|
2023-09-28 18:39:51 -04:00
|
|
|
If `Cow` already owns the data it doesn't need to clone it when `to_mut()` is
|
|
|
|
called.
|
2022-12-31 19:32:38 -05:00
|
|
|
|
2023-02-14 14:37:33 -05:00
|
|
|
Check out https://doc.rust-lang.org/std/borrow/enum.Cow.html for documentation
|
2022-12-31 19:32:38 -05:00
|
|
|
on the `Cow` type.
|
|
|
|
"""
|
|
|
|
|
2023-06-03 10:20:29 -04:00
|
|
|
# THREADS
|
|
|
|
|
|
|
|
[[exercises]]
|
|
|
|
name = "threads1"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/20_threads/threads1.rs"
|
2023-06-03 10:20:29 -04:00
|
|
|
mode = "compile"
|
|
|
|
hint = """
|
|
|
|
`JoinHandle` is a struct that is returned from a spawned thread:
|
|
|
|
https://doc.rust-lang.org/std/thread/fn.spawn.html
|
|
|
|
|
|
|
|
A challenge with multi-threaded applications is that the main thread can
|
|
|
|
finish before the spawned threads are completed.
|
|
|
|
https://doc.rust-lang.org/book/ch16-01-threads.html#waiting-for-all-threads-to-finish-using-join-handles
|
|
|
|
|
2023-09-28 18:39:51 -04:00
|
|
|
Use the `JoinHandle`s to wait for each thread to finish and collect their
|
|
|
|
results.
|
|
|
|
|
2023-06-03 10:20:29 -04:00
|
|
|
https://doc.rust-lang.org/std/thread/struct.JoinHandle.html
|
|
|
|
"""
|
|
|
|
|
|
|
|
[[exercises]]
|
|
|
|
name = "threads2"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/20_threads/threads2.rs"
|
2023-06-03 10:20:29 -04:00
|
|
|
mode = "compile"
|
|
|
|
hint = """
|
|
|
|
`Arc` is an Atomic Reference Counted pointer that allows safe, shared access
|
|
|
|
to **immutable** data. But we want to *change* the number of `jobs_completed`
|
|
|
|
so we'll need to also use another type that will only allow one thread to
|
|
|
|
mutate the data at a time. Take a look at this section of the book:
|
|
|
|
https://doc.rust-lang.org/book/ch16-03-shared-state.html#atomic-reference-counting-with-arct
|
|
|
|
and keep reading if you'd like more hints :)
|
|
|
|
|
|
|
|
Do you now have an `Arc` `Mutex` `JobStatus` at the beginning of main? Like:
|
2023-09-28 18:39:51 -04:00
|
|
|
```
|
|
|
|
let status = Arc::new(Mutex::new(JobStatus { jobs_completed: 0 }));
|
|
|
|
```
|
2023-06-03 10:20:29 -04:00
|
|
|
|
2023-09-28 18:39:51 -04:00
|
|
|
Similar to the code in the example in the book that happens after the text
|
|
|
|
that says 'Sharing a Mutex<T> Between Multiple Threads'. If not, give that a
|
|
|
|
try! If you do and would like more hints, keep reading!!
|
2023-06-03 10:20:29 -04:00
|
|
|
|
|
|
|
Make sure neither of your threads are holding onto the lock of the mutex
|
|
|
|
while they are sleeping, since this will prevent the other thread from
|
|
|
|
being allowed to get the lock. Locks are automatically released when
|
|
|
|
they go out of scope.
|
|
|
|
|
|
|
|
If you've learned from the sample solutions, I encourage you to come
|
|
|
|
back to this exercise and try it again in a few days to reinforce
|
|
|
|
what you've learned :)"""
|
|
|
|
|
|
|
|
[[exercises]]
|
|
|
|
name = "threads3"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/20_threads/threads3.rs"
|
2023-08-26 19:06:01 -04:00
|
|
|
mode = "test"
|
2023-06-03 10:20:29 -04:00
|
|
|
hint = """
|
2023-09-28 18:39:51 -04:00
|
|
|
An alternate way to handle concurrency between threads is to use an `mpsc`
|
|
|
|
(multiple producer, single consumer) channel to communicate.
|
|
|
|
|
|
|
|
With both a sending end and a receiving end, it's possible to send values in
|
|
|
|
one thread and receive them in another.
|
|
|
|
|
|
|
|
Multiple producers are possible by using clone() to create a duplicate of the
|
|
|
|
original sending end.
|
|
|
|
|
2023-06-03 10:20:29 -04:00
|
|
|
See https://doc.rust-lang.org/book/ch16-02-message-passing.html for more info.
|
|
|
|
"""
|
|
|
|
|
2020-12-07 09:37:19 -05:00
|
|
|
# MACROS
|
|
|
|
|
|
|
|
[[exercises]]
|
|
|
|
name = "macros1"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/21_macros/macros1.rs"
|
2020-12-07 09:37:19 -05:00
|
|
|
mode = "compile"
|
|
|
|
hint = """
|
|
|
|
When you call a macro, you need to add something special compared to a
|
|
|
|
regular function call. If you're stuck, take a look at what's inside
|
|
|
|
`my_macro`."""
|
|
|
|
|
|
|
|
[[exercises]]
|
|
|
|
name = "macros2"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/21_macros/macros2.rs"
|
2020-12-07 09:37:19 -05:00
|
|
|
mode = "compile"
|
|
|
|
hint = """
|
|
|
|
Macros don't quite play by the same rules as the rest of Rust, in terms of
|
|
|
|
what's available where.
|
|
|
|
|
|
|
|
Unlike other things in Rust, the order of "where you define a macro" versus
|
|
|
|
"where you use it" actually matters."""
|
|
|
|
|
|
|
|
[[exercises]]
|
|
|
|
name = "macros3"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/21_macros/macros3.rs"
|
2020-12-07 09:37:19 -05:00
|
|
|
mode = "compile"
|
|
|
|
hint = """
|
|
|
|
In order to use a macro outside of its module, you need to do something
|
|
|
|
special to the module to lift the macro out into its parent.
|
|
|
|
|
|
|
|
The same trick also works on "extern crate" statements for crates that have
|
|
|
|
exported macros, if you've seen any of those around."""
|
|
|
|
|
|
|
|
[[exercises]]
|
|
|
|
name = "macros4"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/21_macros/macros4.rs"
|
2020-12-07 09:37:19 -05:00
|
|
|
mode = "compile"
|
|
|
|
hint = """
|
|
|
|
You only need to add a single character to make this compile.
|
2022-07-15 06:05:26 -04:00
|
|
|
|
2023-09-28 18:39:51 -04:00
|
|
|
The way macros are written, it wants to see something between each "macro arm",
|
|
|
|
so it can separate them.
|
|
|
|
|
|
|
|
That's all the macro exercises we have in here, but it's barely even scratching
|
|
|
|
the surface of what you can do with Rust's macros. For a more thorough
|
|
|
|
introduction, you can have a read through 'The Little Book of Rust Macros':
|
|
|
|
https://veykril.github.io/tlborm/"""
|
2020-12-07 09:37:19 -05:00
|
|
|
|
|
|
|
# CLIPPY
|
|
|
|
|
|
|
|
[[exercises]]
|
|
|
|
name = "clippy1"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/22_clippy/clippy1.rs"
|
2020-12-07 09:37:19 -05:00
|
|
|
mode = "clippy"
|
|
|
|
hint = """
|
2023-01-05 11:14:49 -05:00
|
|
|
Rust stores the highest precision version of any long or infinite precision
|
2023-09-28 18:39:51 -04:00
|
|
|
mathematical constants in the Rust standard library:
|
2021-12-15 11:46:27 -05:00
|
|
|
https://doc.rust-lang.org/stable/std/f32/consts/index.html
|
|
|
|
|
2023-09-28 18:39:51 -04:00
|
|
|
We may be tempted to use our own approximations for certain mathematical
|
|
|
|
constants, but clippy recognizes those imprecise mathematical constants as a
|
|
|
|
source of potential error.
|
|
|
|
|
2021-06-29 14:47:32 -04:00
|
|
|
See the suggestions of the clippy warning in compile output and use the
|
2023-09-28 18:39:51 -04:00
|
|
|
appropriate replacement constant from `std::f32::consts`..."""
|
2020-12-07 09:37:19 -05:00
|
|
|
|
|
|
|
[[exercises]]
|
|
|
|
name = "clippy2"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/22_clippy/clippy2.rs"
|
2020-12-07 09:37:19 -05:00
|
|
|
mode = "clippy"
|
|
|
|
hint = """
|
2023-09-28 18:39:51 -04:00
|
|
|
`for` loops over `Option` values are more clearly expressed as an `if let`"""
|
2020-12-07 09:37:19 -05:00
|
|
|
|
2022-07-15 06:28:47 -04:00
|
|
|
[[exercises]]
|
|
|
|
name = "clippy3"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/22_clippy/clippy3.rs"
|
2022-07-15 06:28:47 -04:00
|
|
|
mode = "clippy"
|
|
|
|
hint = "No hints this time!"
|
|
|
|
|
2019-12-16 08:34:30 -05:00
|
|
|
# TYPE CONVERSIONS
|
|
|
|
|
|
|
|
[[exercises]]
|
|
|
|
name = "using_as"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/23_conversions/using_as.rs"
|
2020-09-07 13:09:27 -04:00
|
|
|
mode = "test"
|
2019-12-16 08:34:30 -05:00
|
|
|
hint = """
|
|
|
|
Use the `as` operator to cast one of the operands in the last line of the
|
|
|
|
`average` function into the expected return type."""
|
|
|
|
|
|
|
|
[[exercises]]
|
|
|
|
name = "from_into"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/23_conversions/from_into.rs"
|
2019-12-16 08:34:30 -05:00
|
|
|
mode = "test"
|
|
|
|
hint = """
|
|
|
|
Follow the steps provided right before the `From` implementation"""
|
|
|
|
|
2021-06-24 22:33:41 -04:00
|
|
|
[[exercises]]
|
|
|
|
name = "from_str"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/23_conversions/from_str.rs"
|
2021-06-24 22:33:41 -04:00
|
|
|
mode = "test"
|
|
|
|
hint = """
|
2023-09-28 18:39:51 -04:00
|
|
|
The implementation of `FromStr` should return an `Ok` with a `Person` object,
|
|
|
|
or an `Err` with an error if the string is not valid.
|
2021-06-24 22:33:41 -04:00
|
|
|
|
|
|
|
This is almost like the `from_into` exercise, but returning errors instead
|
|
|
|
of falling back to a default value.
|
|
|
|
|
2022-07-11 07:12:47 -04:00
|
|
|
Look at the test cases to see which error variants to return.
|
2021-06-24 22:33:41 -04:00
|
|
|
|
|
|
|
Another hint: You can use the `map_err` method of `Result` with a function
|
|
|
|
or a closure to wrap the error from `parse::<usize>`.
|
|
|
|
|
|
|
|
Yet another hint: If you would like to propagate errors by using the `?`
|
|
|
|
operator in your solution, you might want to look at
|
|
|
|
https://doc.rust-lang.org/stable/rust-by-example/error/multiple_error_types/reenter_question_mark.html
|
|
|
|
"""
|
|
|
|
|
2019-12-16 08:34:30 -05:00
|
|
|
[[exercises]]
|
|
|
|
name = "try_from_into"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/23_conversions/try_from_into.rs"
|
2019-12-16 08:34:30 -05:00
|
|
|
mode = "test"
|
|
|
|
hint = """
|
2020-06-04 10:31:17 -04:00
|
|
|
Follow the steps provided right before the `TryFrom` implementation.
|
2023-09-28 18:39:51 -04:00
|
|
|
You can also use the example at
|
|
|
|
https://doc.rust-lang.org/std/convert/trait.TryFrom.html
|
2021-05-15 15:01:17 -04:00
|
|
|
|
2022-07-11 07:12:47 -04:00
|
|
|
Is there an implementation of `TryFrom` in the standard library that
|
2021-06-24 22:33:41 -04:00
|
|
|
can both do the required integer conversion and check the range of the input?
|
2021-05-15 15:01:17 -04:00
|
|
|
|
2021-06-24 22:33:41 -04:00
|
|
|
Another hint: Look at the test cases to see which error variants to return.
|
2021-05-15 15:01:17 -04:00
|
|
|
|
2021-06-24 22:33:41 -04:00
|
|
|
Yet another hint: You can use the `map_err` or `or` methods of `Result` to
|
|
|
|
convert errors.
|
|
|
|
|
|
|
|
Yet another hint: If you would like to propagate errors by using the `?`
|
|
|
|
operator in your solution, you might want to look at
|
|
|
|
https://doc.rust-lang.org/stable/rust-by-example/error/multiple_error_types/reenter_question_mark.html
|
2021-05-15 15:01:17 -04:00
|
|
|
|
2021-06-24 22:33:41 -04:00
|
|
|
Challenge: Can you make the `TryFrom` implementations generic over many integer types?"""
|
2019-12-16 08:34:30 -05:00
|
|
|
|
|
|
|
[[exercises]]
|
|
|
|
name = "as_ref_mut"
|
2023-10-16 07:37:12 -04:00
|
|
|
path = "exercises/23_conversions/as_ref_mut.rs"
|
2019-12-16 08:34:30 -05:00
|
|
|
mode = "test"
|
|
|
|
hint = """
|
2023-09-28 18:39:51 -04:00
|
|
|
Add `AsRef<str>` or `AsMut<u32>` as a trait bound to the functions."""
|