Suggestions: Misc

[QuineDot]

• I think you should show the Option and Result definitions here. They'll see the variants everywhere in Rust.

---

• Clarify that a HashMap doesn't have to be keyed with a &str or String (unlike a JSON object, say).

---

• Here, I was going to mention that the lifetime can be explicit in some cases... but upon reconsideration that's probably not worth getting into. However, perhaps you should mention that lifetimes with the same name must indeed be equal. This will matter a lot should they every run into some &'a mut Thing<'a> errors.

But also on that page and on this one, you say

Read &'a Point as “a borrowed Point which is valid for at least the lifetime a”.

That can be misinterpreted as "the borrow is valid for at least 'a", as opposed to "the Point is valid for at least 'a". I.e. it might given the mistaken impression that a borrow can be lengthened.

---

• The getters and setters here aren't very idiomatic. First of all, nothing here is public -- everything must be in the same module -- so you'd just access the fields directly. Second of all, instead of a getter an infallible setter, if the struct was public, you'd probably just make those fields public too. If the fields actually have invariants, the setters shouldn't be infallible, but instead return a Result<_, _>.

More generally, it may give the impression that using getters and setters is idiomatic (even in the same module).

---

• Perhaps note this list of receivers is non-exhaustive. E.g. Box<Self>.

---

• I don't know that "omitted" is the right term for mod in_another_file;. Also perhaps note that (except perhaps for test modules) separate files is the norm.

[mgeisler]

Hey, just a quick comment for one part above:

The getters and setters here aren't very idiomatic. First of all, nothing here is public -- everything must be in the same module -- so you'd just access the fields directly. Second of all, instead of a getter an infallible setter, if the struct was public, you'd probably just make those fields public too. If the fields actually have invariants, the setters shouldn't be infallible, but instead return a Result<_, _>.

More generally, it may give the impression that using getters and setters is idiomatic (even in the same module).

Yes, I agree with you, I should change these getters to do something more complicated.

Perhaps note this list of receivers is non-exhaustive. E.g. Box.

Yeah, thanks!

[fw-immunant]

I think you should show the Option and Result definitions here. They'll see the variants everywhere in Rust.

When teaching, the definition of Option often comes up before the standard library slides are even reached. In any case, whenever going through the standard library slides the slide provides an introduction to the type with usage context and then the standard library docs are the destination for the precise definition if public and to dive deeper into the available methods. See #2248.

Clarify that a HashMap doesn't have to be keyed with a &str or String (unlike a JSON object, say).

This becomes clear on the next slide as well as in the standard library docs where the K, V, and S type parameters are all worth discussing.

The getters and setters here aren't very idiomatic.

These are no longer present, but this exercise could admittedly use some work (#1513).

I don't know that "omitted" is the right term for mod in_another_file;.

To me it makes sense--the body of the mod item is not present in this file, i.e. it is omitted.