You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
tl;dr attempt to coerce everything into a Vec so that we can execute has_length() and friends on anything that impl's IntoIter
I am wondering if there is a way to be able to apply the intersection of the methods on std::collection (or thereabouts) instead of having specializations for Vec and HashMap.
I have a couple ideas... the first would be a naive, hack-y approach which would just be to attempt to call is_empty() or len() etc... directly on the object supplied to assert_that!
This would result in maybe less-than-obvious error messages.. but getting
no method named `has_length` found for type `spectral::Spec<'_, std::collections::BTreeSet<_>>` in the current scope
isn't much better.
My second idea is to make a SpectralCollection type which can be constructed from anything that impls IntoIter.
This would be similar to the Iter set of functionality, but it would construct a "Spectral Collection" of type T (which might just be a Vec) one could then execute the set of Vec's methods against it.
The text was updated successfully, but these errors were encountered:
tl;dr attempt to coerce everything into a Vec so that we can execute
has_length()
and friends on anything that impl's IntoIterI am wondering if there is a way to be able to apply the intersection of the methods on std::collection (or thereabouts) instead of having specializations for Vec and HashMap.
I have a couple ideas... the first would be a naive, hack-y approach which would just be to attempt to call
is_empty()
orlen()
etc... directly on the object supplied toassert_that!
This would result in maybe less-than-obvious error messages.. but getting
isn't much better.
My second idea is to make a SpectralCollection type which can be constructed from anything that impls IntoIter.
This would be similar to the Iter set of functionality, but it would construct a "Spectral Collection" of type T (which might just be a Vec) one could then execute the set of Vec's methods against it.
The text was updated successfully, but these errors were encountered: