Heyo!
I've started writing out my understand of Rust, as I am very much a visual thinker. I just made this cheat sheet for Compound Types and wanted to verify it. Does it seem to be accurate, or is it false / missing something?
3 Likes
It looks entirely correct to me. I'm not sure if you consider the collection types in std::collections to fit in with this cheat sheet. Maybe Option and Result fit in as special cases of enums?
4 Likes
This looks really cool, but I'm afraid if you would try to pull all types even Rust std library have it would quickly became a mess.
There are HashSet, BTreeMap and BTreeSet… how would they fit in that picture, e.g.?
2 Likes
What matters in the end whether the diagram is useful to you, for your way of thinking. That said, here are some observations about things that might be better thought of differently:
-
I'm not sure what the arrows are supposed to indicate; arrays aren't any more or less fundamental or compound than the other items in the chain heading rightward.
-
“Uses instances” isn't something that sounds like a concept in Rust. The thing I would say is particular to
structs andenums are that they are the two kinds of user-defined, named, nominal types — where you say “this is a new type” and specify exactly what data it should hold, from scratch — in Rust. By contrast, arrays and tuples are not “new” types (they are structural rather than nominal): the array type already exists (generically) and you merely choose the element type and length when you use it, and it's the same type as when anyone else uses it, as long as the element type and length match.-
Technically,
VecandHashMapare structs. Since their fields are private, you don't get to treat them in the ways you might a struct you defined yourself, so it's not all that useful to know that they are structs, but it can be useful to note that they are things built out of the primitive kinds-of-types in the language, not a distinct thing. So, I might bucket the types you've mentioned like so (not considering the types not on this chart, like references andBox):- User-defined nominal types: any
struct, anyenum - Generic, primitive containers: arrays, tuples
- Library containers:
Vec,HashMap, and more
The distinction I draw here between primitive containers and library containers does not mean that they have different behavior you have to handle differently; but it is relevant to understanding “how these types got here”. You could define a
Vecof your own if you wanted, but you can't define a new kind of type that's not astructorenum. - User-defined nominal types: any
-
-
An
enumcan have named fields too; in fact anenumis a lot like a combination of severalstructtypes (with some restrictions; you can never usevalue.fieldnamefield access syntax with an enum, only match the variant).
7 Likes
This picture is useful not only by itself, but it has wĐľke here a great explanations for beginners 
2 Likes
Thanks for the replies everyone!
To @kpreid:
-
The arrows represent a progression in logic. I've modified the sheet to better show this, also adding an "in standard library" tag of sorts to Vec and Hasmap:
-
I was basing this off of how the Book explains using Structs and Enums. I think we're saying the same thing in different ways, correct me if I'm wrong?
"To use a struct after we’ve defined it, we create an instance of that struct by specifying concrete values for each of the fields." (From Defining and Instantiating Structs)
- How interesting! That makes sense, thank you for the insight!
-
Are you talking about variants, or do you mean fields as distinct from variants? The book makes it seem like Structs have fields and Enums have variants, so I'm a little confused
The concept “an instance of <some type>” applies equally to any type. It is not exclusive to structs and enums.
It is somewhat more common to need to use it when speaking of structs or enums, because these named types have names that are often drawn from another vocabulary: we might write, for example, “an instance of Image” rather than “an image” because we want to distinguish that we are talking about the specific Image type we've defined rather than an image in general that might be represented in many different ways with many different types (e.g. a file or byte array containing compressed data, rather than a structure); or we want to emphasize that we are talking about a particular bit of memory with particular data in it, rather than the meaning of that data.
(You might also find people that feel that “instance” is a term that belongs to object-oriented programming (“instance of a class”) and that when not speaking of classes one should use the term “a value of <type>” instead. I feel that there isn't much benefit to making that distinction, outside of any particular language's formal terminology.)
Are you talking about variants, or do you mean fields as distinct from variants? The book makes it seem like Structs have fields and Enums have variants,
To be precise: structs have zero or more fields, and enums have zero or more variants, and each variant of an enum has zero or more fields.
2 Likes
Ah, I understand now.
Oh, I see, cool! After digging around the book some more, I understand what you're saying here.
Thank you! ^^
Just FYI, there are a few other popular Rust cheat sheets. There is cheats.rs, although calling it a "sheet" is a bit of a sick joke. It's more like an index to the reference manual. I like this container cheet sheet, although it's a bit low-level. Here is another one nice cheat sheet, when you ask yourself "which of those smart pointers should I use". And the periodic table of pointers is just nice in general.
5 Likes
This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.