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
But I'm wondering if we should have a version of it without const-generics (so a boxed slice internally) as it would allow to have the feature with a n unknown at compile time, similar to slice.windows(n).map(f).
#[cfg(feature = "use_alloc")]
fn map_boxed_windows<F, R>(self, n: usize, f: F) -> MapBoxedWindows<Self, F> // or any other names
where
Self: Sized,
F: FnMut(&[Self::Item]) -> R;
It can have a very similar internal implementation: a boxed slice of length 2 * n to reduce moves (move all windows' elements one time each n elements).
It could have a boxed slice of minimal length n (to minimize allocation) at the cost of moving all the windows' elements every time (with .rotate_left(1)).
Both allocate once.
The first one would be my choice but the second would be simpler and easier to review.
We could also wait for lending iterators to discard F entirely, but it's gonna be a long wait.
The text was updated successfully, but these errors were encountered:
As of today,
Iterator::map_windows
is nightly:But I'm wondering if we should have a version of it without const-generics (so a boxed slice internally) as it would allow to have the feature with a
n
unknown at compile time, similar toslice.windows(n)
.map(f)
.2 * n
to reduce moves (move all windows' elements one time eachn
elements).n
(to minimize allocation) at the cost of moving all the windows' elements every time (with.rotate_left(1)
).Both allocate once.
The first one would be my choice but the second would be simpler and easier to review.
We could also wait for lending iterators to discard
F
entirely, but it's gonna be a long wait.The text was updated successfully, but these errors were encountered: