`Collection[WithId]::new()` could take any kind of iterable instead of a `Vec` about transit_model HOT 3 CLOSED

I experimented this implementation but here are the problems.

If the new method is changed to

pub fn new(v: I) -> Result<Self>
where
	I: IntoIterator<Item = T>;

Then the implementation will call .into_iter() then .collect() to collect as a Vec. If the input parameter is already a Vec, this is an aberration to iterate over it in order to collect it again as a Vec.

Another solution would be to provide a From<IntoIterator<Item = T>> implementation. But this one causes also a problem. Below is a possible implementation.

impl<T: Id<T>, I: IntoIterator<Item = T>> From<I> for CollectionWithId<T> {
    fn from(iterator: I) -> Self {
        // This cannot fail since there will be a unique identifier in the
        // collection hence no identifier's collision.
        CollectionWithId::new(iterator.into_iter().collect()).unwrap()
    }
}

But it does not compile since it creates a conflicting implementation.

error[E0119]: conflicting implementations of trait `std::convert::From<collection::CollectionWithId<_>>` for type `collection::CollectionWithId<_>`:
   --> collection/src/collection.rs:405:1
    |
405 | impl<T: Id<T>, I: IntoIterator<Item = T>> From<I> for CollectionWithId<T> {
    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
    = note: conflicting implementation in crate `core`:
            - impl<T> std::convert::From<T> for T;

error: aborting due to previous error

Anyone has some ideas about that?

from transit_model.

Note that there is a FromIterator trait that could be implemented but this option has already been explored and rejected in #291.

from transit_model.

Therefore, let's close this issue (especially since this functionality has moved to its own repository now hove-io/typed_index_collections).

from transit_model.