* Update lifetimes-function-calls.md
I am trying to describe the problem lifetimes solve. It may seem they are complex and useless, but the paragraph starts from the problem Rust cannot
solve on it's own (yet). Then the paragraph illustrates the problem represented in the code and how lifetimes solve it.
* Update lifetimes-function-calls.md
Moving the generic explanation of why lifetimes are important to the speaker notes.
* Make language more direct
Co-authored-by: Martin Geisler <martin@geisler.net>
* Update mutex.md
Adding speaker notes why Rust `Mutex` has its design and mentioning briefly `RwLock`.
Someone from the audience can notice `unwrap()` in the code, it might be worth to have the answer in speaker notes.
* Apply suggestions from code review
Co-authored-by: Martin Geisler <martin@geisler.net>
* Update channels.md
Adding speaker notes explaining why `send` and `recv` can fail.
* Explicitly mention that the channel is closed when the sender/receiver is dropped
Co-authored-by: Martin Geisler <martin@geisler.net>
* Extract common build steps to composite actions
This allows us to repeat ourselves less across the different jobs.
I also tested using a “reusable workflow” to factor out the common
steps. However, this starts a separate job without a shared
filesystem, which in turn requires us to upload/download artifacts
when we want to use them in several jobs. The artifacts are downloaded
one-by-one and this adds delays and extra steps to all jobs.
* Move Rust cache setup to its own build step
This made it easy to consistently setup the caching of our nested
projects via the “workspacs” config key.
* Update result.md
Adding a speaker note that `Result` documentation is a recommended read.
* Adding a note why `Result` encourages error checking.
* Wordsmithing
Co-authored-by: Andrew Walbran <qwandor@google.com>
* Update iterator.md
Adding a Speaker Note emphasizing that all most all functional programming toolbox over collections can be found in the `Iterator` documentation.
* Wordsmithing
Co-authored-by: Andrew Walbran <qwandor@google.com>
* Update match-guards.md
Adding more information how match guards are different from simply using "if" inside of the match case, after the case has matched.
* Be consistent about naming of match arms.
Co-authored-by: Andrew Walbran <qwandor@google.com>
* Update box-recursive.md
Adding Speaker Notes. This is a high-level guideline what to say, so we can settle on one explanation and review it.
This may be very obvious with the background in some languages, but be very non-obvious in languages that always
use references and never embed structs into structs.
* Fix wording
Co-authored-by: Andrew Walbran <qwandor@google.com>
* Update if-expressions.md
Adding a note about types of `if` branch blocks.
* Fix typo and simplify.
Co-authored-by: Andrew Walbran <qwandor@google.com>
The key takeaway is mutability of receivers and the rules that come with it. It might be a repetition of borrow checker rules, but it is important to know they apply to `self` as to any other variable or argument.
* Update tuple-structs.md
I am adding more information about newtypes. The speaker can get questions about it or may wish to encourage this great pattern.
* Fix typos and explanation
Co-authored-by: Andrew Walbran <qwandor@google.com>
* Update lifetimes-data-structures.md
The example is quite simple, but in it's simplicity it may raise the question why do we even need lifetimes in the structs? Isn't it obvious that the referenced value should always outlive the struct? This sentence tries to explain that more complex cases exist.
* Fix typo
Co-authored-by: Andrew Walbran <qwandor@google.com>
Introducing `Self` type that students can encounter in many places and nice to use. It is only mentioned later in the course, but it is not defined currently.
* Update the Speaker Notes of the type-inference.md
I think this is one of the critical moments in understanding Rust. This behavior is different from many static and dynamic programming languages.
* Fix typo
Co-authored-by: Andrew Walbran <qwandor@google.com>
I suggest to clarify that you only need to implement `From` and nobody really implements `Into` as soon as `From` is implemented.
I decided to add a separate paragraph after the `i8` and `i16` example, as they provide intuitive understanding of reverse relationship between `From` and `Into`. Alternatively trying to explain `From` and `Into` in generic way sounds more confusing than just adding this sentence after the specific example.
* Update Speaker Notes for compile-time.md
The definition of memory leaks is indeed blurry, so it is important not have right expectations about this particular kind of error.
Co-authored-by: Martin Geisler <martin@geisler.net>
