Heap pre-allocation (for capacity, not dynamic sizing)

[rrichardson]

This was discussed a bit in #18, but I have a need for an exceedingly fast, zero-runtime-allocation Sorted Map. We need to hand a few dozen GBs to the SGMap. That's not something we'd ever be able to put on the stack :)

If Scapegoat SGMap could possibly be parameterized to use TinyVec::SliceVec instead of ArrayVec, we'd have everything we need. Scapegoat could remain no-std and fully safe. We'd be doing the unsafe stuff (MMapping actually) to supply the slice to TinyVec::SliceVec

I think it would be simplest to have a feature flag slice-vec that swapped out the ArrayVec for a SliceVec, and introduced a from_slice or with_slice? associated function.

If this or something similar is amenable, I would be happy to submit a PR

[tnballo]

Hey! Thanks for sharing this usecase and identifying a path forward to support it - that'd be an awesome addition to this library and I'm happy to accept a PR adding the functionality and a corresponding from_slice constructor while maintaining no-std/fully-dependency-chain-safe.

Taking a quick look at TinyVec::SliceVec, the signature includes a lifetime for the backing slice. Do you anticipate a slice-vec feature flag will be possible without a breaking API change (e.g. v2.x -> v3.x crate version)? Thinking it may require:

• From: SgSet<T: Ord + Default, const N: usize>
  • To: SgSet<'s, T: Ord + Default, const N: usize>
• From: SgMap<K: Ord + Default, V: Default, const N: usize>
  • To: SgMap<'s, K: Ord + Default, V: Default, const N: usize>
• From: {SgSet,SgMap}::new()
  • To: ??? (cannot support no-arg constructor on slice-based?).

If possible without breaking changes, a slice-vec feature sounds good.

Alternatively, we could add a second set of types - let's say they're called SgSetSlice and SgMapSlice - that have signatures with the additional lifetime (and from_slice instead of new) but are thin wrappers over common/re-used logic internally. Then we could do a 2.X crate release that doesn't break existing uses while supporting the new use case you've described (and others like it).