Returning Vec if Vec1::from() fails doesn’t make sense

[Profpatsch]

It can only ever be an empty Vec, so

pub fn from_vec( vec: Vec<T> ) -> Option<Vec1<T>> {
        if vec.len() > 0 {
            Some( Vec1( vec ) )
        } else {
            None
        }
    }

would be a more sensible interface

[rustonaut]

We would have to at last return an error type.

The thing is the Vec might be empty, but have GB of allocated and previously used memory in it.

Hm, through for the same reason we might really not want to return the Vec wrapped inside a error as this would prevent the memory from being freed.

So I guess Option it is (I mean the large capacity Vec case where the Vec should be re-used is most likely super rare, so we can ignore it here).

[rustonaut]

There is now a new version (1.2.0).

I first wasn't sure if I like Option and that's a braking change, and then a lot of (unrelated) work came my way so it took a while but now it's finally done.

The changes ended up like following:

• Return a Result<Self, Size0Error>. Option<Vec<T>> is just not fully right as it's a failed operation and not one which might or might not return a value. Also it's simple to turn a Result into a Option (e.g. .ok() or .ok()?). But the other way around just doesn't feel right. E.g. you would have to do something like .ok_or(Size0Error), but adding a error from a library to a function of that same library seems to be just not right. So a Result it is.
• It's a small but reasonable change, but having a braking change because of it seems a bit to much. Thinking about it a bit more I felt that the correct way would be to not provide a function but implement TryFrom. But it's not yet stable so we have to have a method, but using try_from is sub-optimal (due to name collision). So choosing try_from_vec seems a good name. So I ended up deprecating from_vec and added a new try_from_vec method to replace it.
• There is also a TryFrom implementation, but behind a feature named unstable-nightly-try-from-impl.