Make HeaderVec more Vec like

[cehteh]

Whats your opinion about breaking changes that make HeaderVec more Vec like? With the long-time goal to be mostly a drop in replacement to std::Vec where it makes sense. Of course it needs to retain its unique API as it has now (access to the header, HeaderVecWeak, the atomic API I added)

notably change/additions:

• Deref should result in &[T] not the header. provide a public .header() method to get the user header (the internal header() has to be renamed )
• reserve all method names of std::Vec to be implemented opportunistically, there are a lot, many are somewhat uncommon and don't need to be implemented ASAP. .get() is most importantly missing, many others are also prolly only oneliners, like .iter() etc
• add a "stdlib" feature, then methods that require std things can be conditionally included
• implement (most of) the Traits that std::Vec implements for HeaderVec as well (possibly guarded by the stdlib feature)

[cehteh]

note to self: PR for 'try_reserve()'

Geordon: whats your opinion about this ticket. Since it would come with some breaking changes it would justify to be scheduled for a 2.0 version. I have some interest in this std::vec compatibility thus I can do the groundwork, but i would only PR the methods i am actually needing.

[vadixidav]

Sorry for the delay. I would love for HeaderVec to approximate Vec as much as possible. As you can see, I am a bit lax on maintaining the library, but if we make impls equivalent to Vec where appropriate, then those will be evergreen and we shouldn't need to spend much time updating them. I had wanted to do this from the beginning, but I really only put in the work to get the library to where I needed it for the hgg crate.

[cehteh]

On Thu, 16 Jan 2025 11:24:14 -0800 Geordon Worley ***@***.***> wrote: Sorry for the delay. I would love for `HeaderVec` to approximate `Vec` as much as possible. As you can see, I am a bit lax on maintaining the library, but if we make impls equivalent to `Vec` where appropriate, then those will be evergreen and we shouldn't need to spend much time updating them. I had wanted to do this from the beginning, but I really only put in the work to get the library to where I needed it for the `hgg` crate.

I am started (and working right now on it) to integrate HeaderVec into CowStr, and I noticed that this will need a bit more work (including Vec compatibility), currently working with a local copy which is ok. I want to have a working PoC before nagging you again. This will take a bit time. Eventually I could offer you co-maintaining HeaderVec when you could put that trust in me. But I certainy would be equally lazy for things that go beyond my own needs :D. Still that halves the lazyness... Christian

[cehteh]

Well Duh .. I noticed that implementing Drain and Splice which I'll need with need some significant/breaking changes.
I pushed those to a WIP PR #13. This will be a bit more work and may take some time as i am busy with other things as well.
Still I would like to get some initial feedback about the changes soon, because proposing significant breaking changes into someone else library isn't something I normally like to do.

[cehteh]

Note: I integrated HeaderVec into a branched version of CowStr now (FYI: https://git.pipapo.org/cehteh/cowstr/commit/9472ffe520a153def698f1ba187e57845e6f0c19) this works like a bliss. I would like to make a release soon (within a few weeks). Since I can't make released crate depend on a local or git repository but only on a another released crate, may i ask you to make something like a 0.2.0-experimental.0 release with all my PR's applied until you have time for a review? I'd really like to contribute to this crate rather than pushing an maintaining a fork myself.