Feedback on rust book > Patterns

[happybeing]

I'm reading the book in section order and some sections have obvs been switched and the text still assumes the old order. I'm just going to mention that but not point out the occurrences here. However, it may explain some of my confusion, if a section I'm commenting on is silently assuming I've read something that now occurs later.

Firstly, I like Rust and am enjoying reading about it. The most confusing bit so far (a testament to how good the book has been) is "match" which has a very simple example, and "patterns" which uses match to illustrate a several patterns: https://doc.rust-lang.org/book/patterns.html

I can't tell from this what these code samples do, or what most of the patterns mean. Example output would help clarify this, but some of the descriptions probably still need expanding too.

I couldn't make sense of patterns based on these examples.

Match guards appear to show overlapping cases (e.g. "5" would match both "OptionalInt::Value(i) if i > 5" and "OptionalInt::Value(..)"). Does match allow overlapping patterns? If so, what is the behaviour - first match only?

I don't understand how the "ref and ref mut" patterns work - the example seems to just show a matching example. In general the examples don't show what matches and why, what doesn't etc. which leaves a big gap in my understanding.

There may be some implicit knowledge that renders all this clear, but I haven't gained it by reading the book in order to this point.

So far this is the only thing I know I don't understand, which is pretty damn good if true :-)
Also, where's the regexp pattern!? ;-)

[steveklabnik]

I think sample output here would be a great idea, for sure.

To answer the questions quickly, the patterns match in order: so the OptionalInt case, if i is 5, that will match, because it comes before the .. case.

[happybeing]

Just to clarify further.. So a maximum of one case will 'match'?

On 13/04/15 21:41, Steve Klabnik wrote:

I think sample output here would be a great idea, for sure.

To answer the questions quickly, the patterns match in order: so the OptionalInt case, if i is 5, that will match, because it comes before the .. case.

---

Reply to this email directly or view it on GitHub:
#24388 (comment)

[steveklabnik]

Yup.

[happybeing]

This comment is a placeholder that you might take as additional feedback, but its just raw braindump while I'm reading. Consider the following work in progress that I may re-visit and edit/delete: UPDATE: consider this comment FINAL!

Trait Objects https://doc.rust-lang.org/book/trait-objects.html

I get most of the explanations of dispatch, but while I do recall the basics of vtables from C++ (last touched >10yrs ago) I can't follow the explanation of representation, either because I've not got the information I need at this point (missing sections? inadequate attention and understanding on my part? inadequate explanation on yours? I'm not sure) or because I'm being slow to understand (my normal).

I'm also left wondering why you've gone into this depth in a "read to use" section of the book. Is it appropriate here? It seems to be documenting something that would only be of interest to compiler writers or those really needing to stretch the capabilities of the compiler.

One thing that I've not grasped yet and which makes it a bit harder for me to understand the vtable explanation examples is the meaning of () within:

pub struct TraitObject {
    pub data: *mut (),
    pub vtable: *mut (),
}

I'm taking it as "collection" but not sure yet. I'm also unsure about why things are cast within the bodies of functions instead of forced outside to the caller. Essentially with my level of understanding at this point I'd need leading through the examples in much finder detail than is appropriate for a section that I take to be describing compiler implementation, and not really about documenting the language and its use to a newcomer.

Closures https://doc.rust-lang.org/book/closures.html

I'm also foundering while reading about ownership with regard to closures, from quite early on. Possibly because I need to go back and understand ownership better, but also possible because the explanations are too thin for me. I'm just noting this at this stage so I can re-visit, but for now I'll probably skip on.

Closure implementation

Link to dispatch section needs fixing up
Examples refering to Traits use inheritance operator and syntax that has not been introduced yet, i.e. use of : in:

pub trait Fn<Args> : FnMut<Args> {
    extern "rust-call" fn call(&self, args: Args) -> Self::Output;
}

Side note: overall I like the literary style, but some terms appear idiomatic and give me difficulty. For example, I am not familiar with the use of 'sugar' in "The || {} syntax for closures is sugar for these three traits." So I have no idea what that means!

Associated types http://doc.rust-lang.org/nightly/book/associated-types.html

fmt::Display which I take it is a part of a standard Rust Trait library, is used before it has been introduced, as in:

trait Graph {
    type N: fmt::Display;
    type E;

    fn has_edge(&self, &Self::N, &Self::N) -> bool;
    fn edges(&self, &Self::N) -> Vec<Self::E>;
}

Reflections

Ok, I've read carefully all the stuff I can really understand and skimmed/deferred things that are not accessible at my level (all noted above) or not needed for someone wanting to get a basic understanding of Rust in order to begin writing some not too complex code. In the latter case I read and or skimmed stuff on macros, and compiler plugins etc. but didn't worry about understanding them.

On reflection there were things introduced relatively early that I've not found explained anywhere. Naturally this left me guessing, and overly relying on earlier knowledge, from C++ in particular. Someone coming straight to Rust would have a much harder time. Even now, I'm still not sure how good my guesses were, and my learning is certainly less for not knowing what some things were as I proceeded, and not having links provided to allow me fill in the gaps at the point they were introduced (or indeed anywhere in the book in its present incomplete form).

Two cases stand out but there may have been others that I don't recall:

• http://doc.rust-lang.org/nightly/book/documentation.html which introduces the type variable syntax along with some predefined types: Result<T, E>, then describing the conditions under which it returns Err(E) is a nice thing to do. This is slightly less important than Panics. Later it was explained that, T is idiomatic for type but until then I was left wondering if it was an identifier and not just chosen for its (obtuse at this point) descriptiveness.
• references to Box and fmt and so on are never explained, but play an important part in the examples. There's also no reference to documentation for these, and would have helped considerably. I'm now off to find it!

Rust is great, and I'm very much liking the book. I think it is well written and easy to follow - a nice balance between concise and thorough, that appears to cover everything (notwithstanding the "coming soons"). A helluva achievement IMO. Thanks!

Late addition:

• I don't think the notation for macros (ie name!) is explained until we get to macros. It would have been helpful to know that's what it was when first encountered in the examples.

[happybeing]

Ok, I've finished my first read through and the preceding comment concludes my feedback. Hope it is helpful. I look forward to updates and adiitions.

[steveklabnik]

Thanks! Dumps always are. I'm hoping to go through this issue sometime this weekend, so I'll check it out then.

[pnkfelix]

@theWebalyst BTW, regarding match and patterns, the most recent blog post may be of interest:

http://blog.rust-lang.org/2015/04/17/Enums-match-mutation-and-moves.html

(Full disclosure : I wrote it)

[happybeing]

Thanks @pnkfelix that looks very useful. Rust is powerful! Have bookmarked it :-)

PS Felix was a fave of mine!

[steveklabnik]

Okay, I've gone through the rest of this too. Thanks again for the feedback. Between the already-open PR, work that's been done since this was filed, and some of the future work I'm doing, I'm going to give this a close, since no specific issue is going to close it. This has been very helpful, thanks again :)