> You have the same restrictions in C++ except with worse consequences. In C++ it is safe because the arena is only used from one thread at a time. To model t

> You have the same restrictions in C++ except with worse consequences. In C++ it is safe because the arena is only used from one thread at a time. To model this C++ pattern in Rust, what I would really want is: 1. Arena should be Sync, and not use interior mutability. 2. Arena::alloc() should do a dual borrow: (a) a mut borrow of the Arena metadata, only for the duration of the alloc() call, and (b) a non-mut (shared) borrow of the Arena data. Because this kind of split borrow cannot be expressed in Rust AFAICS, (2) is not possible, so (1) is not feasible. This forces Bumpalo to be !Sync, which makes a direct Rust port of the C++ pattern impossible. I've heard this called the "factory problem" for Rust: you cannot easily make a factory type in Rust that returns references, because if the create() operation mutates the factory, then the returned reference will have a mutable borrow on the factory. The alternative would be to make a truly thread-safe arena/factory, which could be Sync with interior mutability, but that is an efficiency compromise due to synchronization overhead.