Suggestion: add methods such as `String::into_split`, `String::into_chars` and similar for all the `str` iterator-returning methods

[T-Dark0]

For a practical example of where these methods would be useful, consider this:

    // Say the input is expected to look like this:
    //
    // 123 
    // 542 13
    // 1 23 1145
    //
    // i.e space-separated number sequences, one per line.
    // and the corresponding output must be the Vec [123, 542, 13, 1, 23, 1145]
    
    std::io::stdin().lock()
        .lines()
        .flat_map(|line| {
            let line = line.unwrap();
            line.split(' ')
                .map(|num| num.parse::<u32>().unwrap())
        })
        .collect::<Vec<_>>();

The intent of the above code is hopefully clear. It iterates over lines, for each line it iterates over its parts, and ultimately wants to collect them all into a single vector.

Unfortunately, it doesn't compile. This is because line is a String, owned by the closure passed to flat_map. Since the iterator created by split only borrows the string, line ends up being dropped at the end of the iteration, which makes the attempt to return the iterator a lifetime error.

It would be perfectly fine for the iterator to keep the string alive after the closure ends. This could easily be achieved by taking ownership of it, instead of simply borrowing

Would it be possible to add into_split, into_chars, into_lines (and similar methods for all the str methods that return borrowing iterators) to Strings? The idea is that the above snippet would compile if line.split was replaced with line.into_split

[SkiFire13]

The problem with into_split and into_lines is that their iterators would be yielding references to themself, which isn't possible (for an Iterator; a StreamingIterator could, but GATs aren't stable yet). Thus they would have to yield Strings, resulting in lots of heap allocations. I don't think this is a trade-off the stdlib really wants to make.

I can't think of a reason to not have into_chars though.

[T-Dark0]

Oh great, another cool thing that is blocked on GATs

into_chars at least would be nice, granted. Someone on discord also pointed out to me that String::into_bytes already exists, and so does str::bytes, which makes for an annoying name conflict