Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extending the doubly-linked deque #160

Open
SkiFire13 opened this issue May 15, 2020 · 0 comments
Open

Extending the doubly-linked deque #160

SkiFire13 opened this issue May 15, 2020 · 0 comments

Comments

@SkiFire13
Copy link

The "A Bad but Safe Doubly-Linked Deque" example stops at the Iter implementation, mentioning iterator invalidation and that we could pass Nodes all over the place. I think this is a big missed opportunity to explain lifetime annotations.

The plan would be encapsulating the Rc<RefCell<Node<T>>> into two structs and allow immutable borrowing of the element on one and mutable on the other. This hides the Node<T> and also prevents cloning the Rc.
To solve iterator invalidation it's possible to add lifetime annotations tied to the lifetime of the immutable borrow of the LinkedList that the caller creates when it calls iter. This lifetime would be present on both the iterator and the encapsulating structs, ensuring that the caller can't leak elements of the list or modify it when there's an instance of the iterator still alive.

The only downfall would be that the encapsulating structs can't directly implement Deref unless self-referential structs are somewhat added to rust, instead they need to provide an explicit borrow`borrow_mutmethod that returns theRef/RefMutfromRefCell`.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant