You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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`.
The text was updated successfully, but these errors were encountered:
The "A Bad but Safe Doubly-Linked Deque" example stops at the
Iter
implementation, mentioning iterator invalidation and that we could passNode
s 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 theNode<T>
and also prevents cloning theRc
.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 callsiter
. 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 explicitborrow
`borrow_mutmethod that returns the
Ref/
RefMutfrom
RefCell`.The text was updated successfully, but these errors were encountered: