Design safe collection API with compile-time reference stability in Rust

[TennyZhuang]

@steffahn

I fully agree that these kinds of API ideas should use some version of partial borrows if possible.

This is a very useful insight. I didn't realize before that my implementation was actually simulating the scope API.

@steffahn

For that however, remember that VecDeque on .push does re-allocate memory and move elements

This is also something I didn't know before. I mistakenly thought that the Vec in VecDeque referred to allocating multiple segments of Vec. I just finished looking at the underlying implementation of VecDeque. Indeed, this example is wrong. Maybe only LinkedList in std collections wouldn't move elements?

@steffahn

For examples, a fn push_and_take_mutable_reference(self: &mut Vec<T>, elem: T) -> &mut T style method

The case is similar to get_many_mut, I don't think it can be achieved at compile time, unless the structure itself is multi-version, and we can only allow the get on a previous snapshot after push_and_take_mutable_reference .

@steffahn

One thing that your article doesn’t mention: of course some use-cases could also be addressed by an API that makes the collection !Sync and permits mutability to the structure through interior mutability.

I've tried that, but !Sync types are really too hard to use in a tokio runtime, and tokio is almost the de facto standard for async Rust., so I don't mention it here. It's another problem that how !Sync types can be more usable in async rust.

@steffahn

Your article makes me think that !Sync protected interior-mutability based APIs could also work with a scope-ish model, or rather, simpler, with a fn (&'a mut self) -> HelpfulWrapper<'mut, …> API, so you can have only some section of the code use the otherwise ordinary (and thread-safe) collection in such a manner. (With such “scoped” access, they could even both exist! Both a !Sync interior-mutable structure API and a ValuePerm one.)

I'm glad that my article can provide some better ideas for designing Rust APIs.

@steffahn

Here are a few notes I’ve had while reading:

Thank you very much for these notes. They are very helpful in refining my article, and I will make the revisions ASAP. This can also help more readers (I may submit the article to next TWIR) better understand my ideas.