Consider removing the `_iter` suffixes on specialized Iterator constructors

[Kimundi]

The names tend to become increasingly long, and if there is no alternative way it seems silly to add to the name. The _iter suffix can still be used for cases where an operation is also implemented in a non-iterator way, or where no better name can be found.

For example, the iterator constructors for StrSlice would improve greatly from this:

byte_iter()             -> bytes()
byte_rev_iter()         -> bytes_rev()
char_offset_iter()      -> chars_offset()
char_offset_rev_iter()  -> chars_offset_rev()
split_iter()            -> split()
rsplit_iter()           -> rsplit()
splitn_iter()           -> split_n()
rsplitn_iter()          -> rsplit_n()
split_terminator_iter() -> split_terminator()
split_str_iter()        -> split_str()
matches_index_iter()    -> match_indices()
line_iter()             -> lines()
any_line_iter()         -> lines_any()
word_iter()             -> words()
// Can't think of something shorter for these two:
nfd_iter()              -> nfd_iter()
nfkd_iter()             -> nfkd_iter()
// These would be Iterable impls, and thus keep the name:
iter()                  -> iter()
rev_iter()              -> rev_iter()

[alexcrichton]

I am totally in favor of this.

[alexcrichton]

I suppose I should elaborate a bit more. I personally don't like the _iter suffix everywhere when using iterators (especially in struct names), but I do agree that there are locations in which it is appropriate. I think that the four methods you've listed as retaining iter in them are appropriate, but all of the others I believe are just as natural without _iter than with.

It could be difficult in that words doesn't necessarily indicate that you're getting an iterator instead of an array, but I think that this isn't too bad.

If we do push forward with this, I think that other modules in libstd/extra should be checked to ensure that they adhere to this same convention, which is basically: "Does it make sense without _iter? Then you can probably drop it."

[Kimundi]

@alexcrichton Right, the idiomatic way should be to offer an lazy evaluating Iterator for all operations where you're computing an stream of values, so once we standarized on that it would become unidiomatic for something like words() to not return something like a WordIterator.

[huonw]

👍 I'd almost say that str.iter should be str.chars since we don't have Iterable yet.

[kud1ing]

Could we always return an iterator where we return a list today?
Would words().collect() be more expensive than words() which returns a list? Or would that be optimized away?

[thestinger]

It will rarely be less efficient, because the iterator's next function will be inlined and the struct removed by scalar replacement of aggregates (SROA).

The only case I can think of where there's an efficiency issue is when you're replacing recursive traversals with an iterator managing a stack. The reason simply being that the iterator is usually going to have to allocate the stack, but if it can be done up-front then it will be cheaper than recursion.

[kud1ing]

@ thestinger: Thanks. Then i suggest porting everything to iterators. A _iter suffix would then be superfluous, because we would not need to distinguish between functions returning iterators or lists.

On second thought, str::chars().collect() will certainly be less efficient than just charing the internal data structure.

[Kimundi]

@huonw: That is my opinion too - iterating over a string should not prefer any of the three possibilities of bytes, codepoints, and grapheme clusters. I elaborated a bit on that here: #7043

EDIT: Which I just realized yourself opened, so you already know :P

[bluss]

I think char_offset_iter() could be → char_indices() (it's really chars and their byte indices)

Regarding chars().collect() it has an issue with the size_hint which I'm unsure how to solve. The problem is that a char may require 1-4 bytes of allocation in the str. CharIterator uses the lower bound for its size hint and guesses that every remaining byte is part of a 4-byte encoded char. FromIterator for str however, I think it just allocates the lower bound of bytes, so it assumes 1 byte per char! This is unfortunately a pessimisation for the ascii case. (Edit: The worst part is that I've written both of the methods).

[Kimundi]

This got solved by #10622