]> git.lizzy.rs Git - rust.git/commitdiff
Auto merge of #51339 - sdroege:exact-chunks-remainder, r=alexcrichton
authorbors <bors@rust-lang.org>
Thu, 12 Jul 2018 19:39:04 +0000 (19:39 +0000)
committerbors <bors@rust-lang.org>
Thu, 12 Jul 2018 19:39:04 +0000 (19:39 +0000)
Add ExactChunks::remainder and ExactChunks::into_remainder

These allow to get the leftover items of the slice that are not being
iterated as part of the iterator due to not filling a complete chunk.

The mutable version consumes the slice because otherwise we would either
a) have to borrow the iterator instead of taking the lifetime of
the underlying slice, which is not what *any* of the other iterator
functions is doing, or
b) would allow returning multiple mutable references to the same data

The current behaviour of consuming the iterator is consistent with
IterMut::into_slice for the normal iterator.

----

This is related to https://github.com/rust-lang/rust/issues/47115#issuecomment-392685177 and the following comments.

While there the discussion was first about a way to get the "tail" of the iterator (everything from the slice that is still not iterated yet), this gives kind of unintuitive behaviour and is inconsistent with how the other slice iterators work.

Unintuitive because the `next_back` would have no effect on the tail (or otherwise the tail could not include the remainder items), inconsistent because a) generally the idea of the slice iterators seems to be to only ever return items that were not iterated yet (and don't provide a way to access the same item twice) and b) we would return a "flat" `&[T]` slice but the iterator's shape is `&[[T]]` instead, c) the mutable variant would have to borrow from the iterator instead of the underlying slice (all other iterator functions borrow from the underlying slice!)

As such, I've only implemented functions to get the remainder. This also allows the implementation to be completely safe still (and around slices instead of raw pointers), while getting the tail would either be inefficient or would have to be implemented around raw pointers.

CC @kerollmops


No differences found