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
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?
The text was updated successfully, but these errors were encountered:
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.
I noticed that some methods return
Vec
s. In particular, it'sstride
andscalar_collect
. I was wondering if it made sense to expose generic version that could use arbitraryFromIterator
type. My motivation for this is:The original methods could still be preserved, as wrappers with
Vec
implementation. Does it make sense? Should I send a pull request for that?The text was updated successfully, but these errors were encountered: