Skip to content

Eccentric FixedVec interfaces–A wish list #11

@197g

Description

@197g

Not managing the allocation within FixedVec makes some rather outlandish interfaces necessary but also possible. Each should get forked into a separate issue when it gets a better draft or is being worked on. This is a quick sketch/wish list.

  • impl<T> DoubleEndedIterator for Drain<'_, T> { } (closed in FixedVec drain can implement DoubleEndedIterator #19)

  • fn FixedVec::extend_from_within(&mut self, idx: impl SliceIndex<[T]>)
    fn FixedVec::fill_from_within(&mut self, f: impl FnOnce(&[T]) -> impl Iterator<Item=T>)
    The elements can be borrowed when extend the FixedVec as we never have to relocate them. That's quite awesome.

  • Drain::skip(&mut self). Move an element to the start, then advance over it as if it were not part of the original drain(..) invocation. This would be a useful precursor to DrainFilter as well. An symmetric operation may put it in-front of the tail but needs some naming discussion (skip_back is confusing when double ended iterator should provide the same for the other side).

  • struct SpliceVec<'a, T> {
        // A vector view on the contents but forgotten instead of dropped.
        vec: ManuallyDrop<FixedVec<'a, T>>,
        // Unused tail and capacity of the underlying vec.
        tail_len: usize,
        tail_capacity: usize, 
    }
    
    impl<T> FixedVec<'_, T> {
        splice_vec(&mut self) -> SpliceVec<'_, T>;
    }
    
    impl<'a, T> Deref for SpliceVec<'a, T> {
        type Target = FixedVec<'a, T>;
        // ..
    }

    A splice that works strictly in-place. The elements in the tail of the original FixedVec may be manually shifted backwards to provide more capacity to the splice. No more work is involved exactly if the vector within the Splice is empty when it is dropped.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requesthelp wantedExtra attention is needed

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions