Skip to content
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 generalizations? #15

Open
rrichardson opened this issue Nov 1, 2017 · 0 comments
Open

collection generalizations? #15

rrichardson opened this issue Nov 1, 2017 · 0 comments

Comments

@rrichardson
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant