The Shifgrethor garbage collection blog series and discussion have had me thinking about use cases where Rust's existing memory management tools (language, standard libraries, and popular crates) fall short, or aren't ergonomic.
Full garbage collection as a library is a useful, but big, hammer; as the blog post above puts it, Shifgrethor
is not simpler or more convenient to use than Rust’s normal APIs, for a variety of reasons. Its unlikely, then, that this project will result in garbage collection becoming a commonly used feature by Rust projects.
Instead, idiomatic Rust divides memory usage into different common patterns, and implements them with various smart pointers and so on. On top of that, crates have sprung up to address patterns such as making a reference or data structure own its referenced value (owning_ref) and designing self-referential structs (rental).
That gets me to my question:
TL;DR: what are some patterns you've found in practice where Rust's existing memory management tools (standard library smart pointers, popular crates) are not enough to implement those patterns ergonomically? This relates to, but AFAICT is more specific than, the discussion about the "Rust Patterns" blog series.
To start things off:
- An early pattern that gave me trouble is creating an iterator over the contents of certain smart pointers. The "Rust Patterns" series above explores some workarounds, but they involve non-obvious boilerplate or must be tailored to the specific contained type.
- To generalize the pattern above: it can be frustrating to use types that were designed to hold onto bare Rust references /
PhantomData
-- e.g., the return value ofvec.iter()
orvec.drain()
-- beyond a chosen lexical scope, by holding onto them instruct
s that move or live in the heap and doing something to extend the lifetime of what they refer to. (owning_ref
applies here, but I think there's room to explore the ergonomics further.)