(This is indirectly related to #79) A few examples I was also wondering about, might be worth pondering on - legit collections where direct `.collect()` just doesn't cut it (along with the current `TryIntoCollection` logic). 1. Types like [`vec1::Vec1<T>`](https://docs.rs/vec1/latest/vec1/struct.Vec1.html) (a fairly popular crate for what it does). It can be iterated over but, obviously, doesn't support `FromIterator` because it can fail if there's no items. It also can't implement `Default` and you have to provide the first element into `new(first)`. Serialization is not a problem, but what about deserialization? 2. Any constrained collections, e.g. maybe `EvenVec<T: Integer>` that has a `try_push()` which may fail if the integer is not even. Again, `FromIterator` can't be implemented (but `Default` can be, unlike the previous example). In both of these examples you would probably have them implement `TryFrom<Vec<T>>` or `TryFrom<&[T]>` (or both, depending on whether it uses `Vec<T>` internally or not) - in fact `vec1::Vec1` already implements both. - So, one way would be to convert/collect elements from arrow into a Vec and then `TryFrom`-convert it into your custom collection. I believe this will cover the majority of cases like this. - Another way would be to add support for failures during deserialization (see next example). In regards to fallible deserialization, there's an even simpler example without containers: 3. `struct EvenNumber(i32)` with an `EvenNumber::try_new(i32) -> Result<Self, Error>` fallible constructor. Again, serializing this is fine. But what about deserialization? The current signature returns `deserialize(...) -> Option<T>` which wouldn't support cases like this. 4. Similar example, but from standard library - the family of `NonZero{U,I}*` types - https://doc.rust-lang.org/stable/std/num/index.html.