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

Feature request: multizip_eq (and izip_eq!) #209

Open
jplatte opened this issue Aug 3, 2017 · 3 comments
Open

Feature request: multizip_eq (and izip_eq!) #209

jplatte opened this issue Aug 3, 2017 · 3 comments

Comments

@jplatte
Copy link
Contributor

jplatte commented Aug 3, 2017

Seems the only reason this doesn't exist is that nobody has done it yet. Should I make a PR?

@bluss
Copy link
Member

bluss commented Aug 12, 2017

zip_eq kills performance pretty well, so I've been uncomfortable with it. We could change it around to use exact size iterators and check up front, but that also makes them less useful, doesn't it? Any thoughts on this?

@jplatte
Copy link
Contributor Author

jplatte commented Aug 12, 2017

I wouldn't really have expected it to work with non-ExactSizeIterators. For me it's simply a nice additional assertion (which has already caught one bug for me where I accidentally refered to a wrong slice).

@bluss
Copy link
Member

bluss commented Aug 12, 2017

Aha. For example filtering will make an iterator non-ESI and I can imagine that's exactly when zip_eq is needed, if equal length is the assumption.

Maybe we can give update the "contract" of it to allow it to panic up front, for exact size iterators, but otherwise defer to late checking? That would still "kill" performance until specialization is available, though.

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

2 participants