`impl FromIterator<Item = BitVec<_, _>> for BitVec<_, _>`

[XAMPPRocky]

Hello, one common use-case I face when using bitvec is having a collection of bitstrings that I need to concatenate together. It would be nice if BitVec reflected Vec's and String's implementations of FromIterator on themselves, and allow you to use .collect() to concatenate a iterator of BitVec's into a single BitVec.

[myrrlyn]

I can't find an impl<T> FromIterator<Vec<T>> for Vec<T> in the standard library, though there is an impl FromIterator<String> for String.

I've never considered whether BitVec might have semantic overlap with String before. There's certainly no point making an entirely new BitString type, so, I think you have a point about pulling from the String API as well as the Vec API.

There is, however, the Concat API in slice and Vec, which I have been intentionally ignoring so far with the rationale

As of 1.56, the concat and join methods use still-unstable traits to govern the collection of multiple subslices into one vector. These are possible to copy over and redefine locally, but unless a user asks for it, doing so is considered a low priority.

This is you asking for it, so I'll work on it when I get back from vacation.

Would the Concat trait and slice function suffice? Since BitVec has .extend_from_bitslice(), you can currently simulate impl FromIterator<&BitSlice> for BitVec with

let mut bv = bitvec![];
for bit_slice in dynamic_source_of_bitslices() {
  bv.extend_from_bitslice(bit_slice);
}
bv

I wouldn't be able to make a better optimization than this (since the length of each &BitSlice produced by the iterator is unknowable until the iterator is being actively driven), so the question of whether to expand beyond copying the Vec<bool> interface is largely one of convenience for you.