Repository navigation
Allow accessing the inner ArrayVec of a SequenceOf #665
Description
Hi Tony,
Unless I'm mistaken, in der version 0.6, the inner field of a SequenceOf struct is not public: would it be possible to get a mutable pointer to that ArrayVec? From that, I think I should be able to call any of the methods of slice (e.g. the sort method) on the underlying data since it implements the AsRef structure. Is that correct?
My use case is the following: I am building a lookup table of u32s, stored as a SequenceOf<u32, 256>. Prior to encoding it, I want to ensure it's sorted so I can do a binary search on that data upon loading it.
Another option would be for me to store the data as an ArrayVec and then initialize the SequenceOf from that ArrayVec (probably by moving the data) when encoding it, but that seems less straightforward.
Thanks for your help
Activity
tarcieri commentedon May 22, 2022
Are you specifically trying to avoid heap allocations? If not, then you can use
Vec<u32>instead.ChristopherRabotin commentedon May 22, 2022
tarcieri commentedon May 22, 2022
Right now the
ArrayVectype isn't part of the public API. That's intentional as it enables changing the backing storage without making breaking changes to the API.I would prefer not to expose the current implementation. If we do expose it, I'd prefer to use either a crate like
arrayvecortinyvec, or a prospective implementation incore.ChristopherRabotin commentedon May 22, 2022
That makes sense.
I might not get around to it until a bit, but would the goal be to replace the
ArrayVecwith one of the equivalents fromarrayvecortinyvec? A quick glance seems to indicate that tinyvec is more feature-full compared to arrayvec's equivalent. Do you have any preference? I would opt for tinyvec if I were to make the changes, unless you object of course.tarcieri commentedon May 22, 2022
It might be possible. It would require some investigation, and is likely to require breaking changes, which I'd prefer not to make for awhile as I just cut a
derv0.6 release and am slowly getting everything transitioned to use it.I would have a weak preference for
tinyvecas it uses no unsafe code.Also: at present
derhas no hard dependencies and I'd prefer to keep it that way, so if we were to add it I'd prefer it be optional like the rest of the dependencies.tarcieri commentedon Feb 11, 2026
Closing in favor of #2218: we should probably replace our naive internal
ArrayVecimplementation with a well-maintained optional third party crate. If we do that, I have no problem exposing the inner type: we could doAsRefor what have you.