Fallible deserialization and constrained types/collections

[aldanor]

(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> (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.