I would like to suggest the following, feel free to close if you don't want to follow this path.

• picking SVG as the only source format (e.g. drop ppt), so there is no ambiguity what to edit
• add class attribute to objects in SVG
• use CSS to generate various variants

For example, this is the text node for one of the Type boxes. As you can see, I've added class="normal_label" attribute. You can do it directly in Inkscape as well.

<text               
   class="normal_label"
   inkscape:label="text125"
   fill="#bfbfbf"   
   font-family="Calibri, Calibri_MSFontService, sans-serif"
   font-weight="400"
   font-size="24px" 
   transform="translate(838.371,658)"
   id="text125">Type</text>

I can now create PDF or PNG directly from SVG on commandline with rsvg-convert from librsvg2-bin package (on Debian). For example

rsvg-convert -f pdf rust-memory-container-cs.svg > normal.pdf

will generate PDF as in SVG. So it will look like this

But CSS will allow to change attributes based on selectors, such as classes. So if red_labels.css looks like

.normal_label {
  fill: #ff0000;
}

and covert to pdf with

rsvg-convert -f pdf -s red_labels.css rust-memory-container-cs.svg > styled.pdf

Towards the top of the image, one of the footnotes associates int with integral, which is incorrect when talking about the primitive datatype. See Rust By Example for instance.

I love this project and I use it as wallpaper.
But I have a question about the multiple/unique branch. I feel this branch is unnecessay.
I feel Mutex should always be used inside Arc. Mutex are never used alone.
If there are any example where Mutex is needed in a single thread?

I'm new to Rust and I may confuse something.

While it's in a separate crate, AtomicRefCell seems like a very useful addition here as it expresses slightly different guarantees than Mutex / RWLock, and in the situations where it can be used it has a lot less overhead.

https://docs.rs/atomic_refcell

I love this project and I use it as wallpaper.
But I have a question about the multiple/unique branch. I feel this branch is unnecessay.
I feel Mutex should always be used inside Arc. Mutex are never used alone.
If there are any example where Mutex is needed in a single thread?

I'm new to Rust and I may confuse something.

The infographic suggests that Cell can only be used with Copy types. But you can move anything into a Cell. See the replace method.

From: https://www.reddit.com/r/rust/comments/idwlqu/rust_memory_container_cheatsheet_publish_on_github/g2bsbso/?utm_source=reddit&utm_medium=web2x&context=3

Internal sharing? -[no]--> Allocates? -[no]--> Internal mutability? -[no]--> Ownership? -[no]-----------------------------------> &mut T
      \                     \                                    \                     `-[yes]----------------------------------> T
       \                     \                                    \
        \                     \                                    `-[yes]-> Thread-safe? -[no]--> Internal references? -[no]---> Cell<T>
         \                     \                                                       \                               `-[yes]--> RefCell<T>
          \                     \                                                       \
           \                     \                                                       `-[yes]-> Internal references? -[no]---> AtomicT
            \                     \                                                                                  \ `-[one]--> Mutex<T>
             \                     \                                                                                  `--[many]-> RwLock<T>
              \                     \
               \                     `-[yes]------------------------------------------------------------------------------------> Box<T>
                \         
                 `-[yes]-> Allocates? -[no]-------------------------------------------------------------------------------------> &T
                                    \
                                     `-[yes]-> Thread-safe? -[no]---------------------------------------------------------------> Rc<T>
                                                           `-[yes]--------------------------------------------------------------> Arc<T>
Reply

And, I have an interest to several suggestions for a correctness or details. But, the cheat-sheet favor to a newbiews, and the right columns is not a type, yes I know. I'll make an update with include these reddit users suggestions to the rev1 or a later.

Nice reference! But it's problematic.

Rationale: A little-less-dark on dark background is never good usability.

I think all instances of text should have higher contrast ratios. See https://contrast-ratio.com/ for how this is calculated.

The text in the legend has contrast ratio of just 1.64
https://contrast-ratio.com/#rgb%2858%2C55%2C55%29-on-rgb%2813%2C13%2C13

The text in boxes contrast ratio is just 2.18
https://contrast-ratio.com/#rgb(110%2C105%2C105)-on-rgb(58%2C55%2C55)

This is very basic, but it needs to be emphasized: accessibility and usability matter. A lot.

From: https://www.reddit.com/r/rust/comments/idwlqu/rust_memory_container_cheatsheet_publish_on_github/g2bqrxp/?utm_source=reddit&utm_medium=web2x&context=3

Can you post the graphviz (or whatever you used) source on the repository please so people can more easily make corrections.

• The current original source is .pttx (PowerPoint)
• Option: Add the graphviz ver. or Change the original source format or Reject the issue
• Unfortunately, I author is not an expert of graphviz usage.

See this discussion for context: rust-lang/rust-clippy#4295

Basically, AtomicT is not just “a fast Mutex<T>”, it has many additional properties such as it not supporting locking and it accepting Ordering parameters. It is often harmful to recommend AtomicT as a direct replacement for Mutex<T>, because people can easily make assumptions about how they behave that turn out to not be correct, since their actual behaviour is quite subtle (even just with SeqCst, the model of a Mutex<T> is far simpler as it allows arbitrary mutation while in the “locked” state). I see AtomicT as beïng a very low-level primitive for implementing concurrent data structures; it’s mostly too complex for high-level code. Generally, if someone understands Rust well enough to correctly know how to use atomics, they would not need this chart in the first place.