-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Collection[WithId]::new()
could take any kind of iterable instead of a Vec
#485
Comments
I experimented this implementation but here are the problems. If the pub fn new(v: I) -> Result<Self>
where
I: IntoIterator<Item = T>; Then the implementation will call Another solution would be to provide a 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.
Anyone has some ideas about that? |
Note that there is a |
Therefore, let's close this issue (especially since this functionality has moved to its own repository now |
Today,
Collection::new()
andCollectionWithId::new()
takes aVec<T: Id<T>>
as an input argument. But technically, nothing should prevent us to construct aCollection
or aCollectionWithId
from aHashSet
or aHashMap::values()
.This would mean change the
CollectionWithId::new()
method from (and similar forCollection
)to something like
The text was updated successfully, but these errors were encountered: