5/11/2023 0 Comments Rust the method map exists but![]() ![]() To send a confirmation email you have to stitch together multiple operations: validation of user input, email dispatch, various database queries. ![]() Subscribe to the newsletter to be notified when a new episode is published. This article is a sample from Zero To Production In Rust, a book on backend development in Rust. Then a write to Cell can’t change the structure, there is only one possible structure.A learning journal Error Handling In Rust - A Deep Dive Let’s call the structure of a value ‘flat’ (see this comment) if the references don’t go under indirections ( Box or other wrapper types) or branches ( enums). That would be really useful for larger types, as it allows you to read or write only part of the value. It turns out here is a case where taking a reference to inside the cell doesn’t violate its soundness. The basic convention that makes Cell safe is to never hand out references to its wrapped value. References in Cell if the structure is ‘flat’ But I really don’t see much use for such a type. An alternative could be OnceFlipCell, which comes with an initial state that can be flipped to a usable state. You really want to use compare_and_swap-like methods instead, or something like the experimental fetch_update on atomic integers.įor synchronization primitives something like RefCell::replace_with is also not recommended, because that would mean secretly taking a lock.įor OnceCell it doesn’t make sense to update the value, because the only time its value can be mutated is while it is uninitialized. I wonder if there is much use for replace_with, but it exists.įor synchronization primitives something like Cell::update is tricky, other threads could have modified the value while the closure is running. Because both options are equally valid and both just for convenience, I wonder how long it will take to reach a decision and stabilize the function.įor RefCell::replace_with it is easy: borrowing it again inside the closure causes a panic, just like other invalid borrows. Reads from the cell during the closure will return the old value, and writes will be overwritten after the closure is done.Īn alternative is requiring a Default bound, so that Cell::update takes out the value, reads from the cell during the closure will see a default value, and a new value will be put back in after the closure is done. It will pass a copy of the value to the update closure. These methods run a closure with the current value in the cell as input, and write the result to the value when done.Ī problem is: what happens when you try to access the cell while inside the closure? Cell::update currently has a Copy bound. One trick that is available for single-threaded types is Cell::update ( unstable) or RefCell::replace_with. In that case you can just use the wrapped value, without having to uphold the conventions the wrapper normally asks for in order to use the value with multiple references. If you have exclusive, mutable access, you don’t need interior mutability. Or there is a point where you are done sharing, for example in the Drop implementation of a type. Downgrading or upgrading a smart pointerīypass conventions if you have exclusive accessįor many uses of types with interior mutability there is a point in the program where the value is not yet shared, and you either own the value, or have exclusive access.Temporary lending out a mutable reference to another thread.References in Cell if the structure is ‘flat’.Updating a value (single-threaded wrappers only).mem::replace, but for interior mutability.Temporary wrap a value to provide interior mutability.Bypass conventions if you have exclusive access.We could place these methods in 9 categories: *: possible, but not implemented (or not implemented in the standard library or main crate) ¹: In this post I use Atomic to describe a wrapper based on atomic operations, and AtomicCell to describe a lock-based solution for larger types. Yet there are some creative methods that push the limit of those abstractions. We didn’t look further than the basic API, that was already plenty of material to cover. In the previous post Interior mutability patterns we looked at four different conventions that can be used to safely use interor mutability.
0 Comments
Leave a Reply. |