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