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

Arbitrary collect support #35

Open
vorner opened this issue Apr 23, 2018 · 1 comment
Open

Arbitrary collect support #35

vorner opened this issue Apr 23, 2018 · 1 comment

Comments

@vorner
Copy link
Contributor

vorner commented Apr 23, 2018

I noticed that some methods return Vecs. In particular, it's stride and scalar_collect. I was wondering if it made sense to expose generic version that could use arbitrary FromIterator type. My motivation for this is:

  • It would allow for use in nostd environment, for example with arrayvec.
  • It would allow storing the results on the stack, again with arrayvec or with smallvec (to avoid allocations for the small cases while falling back on it in the big ones when the allocation cost is amortized).

The original methods could still be preserved, as wrappers with Vec implementation. Does it make sense? Should I send a pull request for that?

@AdamNiederer
Copy link
Owner

I like the idea of replacing scalar_collect with something more generic, but I'm curious about what it would mean for applications which process data which is too large to store on the stack. It sounds like a fully generic and no-std implementation would need to collect into some kind of stack-based array and then call T::from_iter() with it regardless of system.

0.5.0 already breaks a ton of the public API presented in 0.4.3, so feel free to rip and tear if you do decide to send a PR.

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