Tracking issue for converting slice iterators to slices

[alexcrichton]

This is a tracking issue for the unstable iter_to_slice feature in the standard library. The into_vec adaptor for vec::IntoIter was recently removed, and these may also want to be removed. It's somewhat unclear how useful it is to have iterators enhanced with this kind of functionality.

[SimonSapin]

I kinda like this method, though I admit I’ve never actually used it :)

This method is probably the simplest way to expose safely something isomorphic to the private fields of the slice iterators (a pair of pointers). All sorts of interesting things that we have not foreseen could be built on top of it outside of std. (Like maybe finding the line number of the current iterator position for error reporting in an interator-based parser with subslice_offset. But whether that specific example makes sense is besides the point.)

If this method is removed without a replacement, there is no way to get at the full information that is carried by slice::Iter. (Without crazy-unsafe transmutes or pointer offseting that guess the struct layout.)

On the other hand, what’s the cost of keeping it? Are there issues with it?

[alexcrichton]

This feature is now entering its final comment period for deprecation

[aturon]

Note that IntoVec was removed not because it wasn't wanted, but because drain provided a superior replacement.

I agree with @SimonSapin that these methods seem harmless and appealing... even if, like @SimonSapin, I haven't used them myself :)

[bluss]

@aturon, I disagree because IntoIter & into vec are useful where drain isn't. I've got a usecase for IntoIter and I'd like to cycle out the IntoIterators and use their allocations again, after they are emptied..

[aturon]

@bluss Right, but my point is, IntoIter was removed, but that's not analogous to removing the slice functionality here, since we don't have anything akin to drain.

[bluss]

@SimonSapin I like your viewpoint. Going back and forth between slices and iterators allows working with them in a kind of random access way, without having to separately count the steps you do in "iterator mode".

[jan-hudec]

Where these functions would be extremely useful is for strings, but I don't see them there.

Basically many string operations require &str, but other are much easier on iterators. Not being able to convert between those representations means a lot of duplicate information needs to be kept and one often needs to resort to char_indices, which is a bit unwieldy. Moreover, often the slice from start to iterator/subslice is needed, e.g. to be passed to std::str::FromStr::from_str. This could be built from as_slice for Chars and subslice_index, but a special function would have the advantage that it could skip the is_char_boundary check, because the slice/iterator were (unless unsafe was used) checked.

[bluss]

run_utf8_validation_iterator shows a use case, but that particular function could just take a &[u8] instead of an iterator. I agree with @jan-hudec, some of my algorithms could absolutely be simplified with to_str() available on the chars iterator.

[SimonSapin]

I’ll submit a PR to add it. to_str or as_str?

[bluss]

I guess as_str() if we keep the as_slice method on slice iterators.