Rfcs: Method naming inconsistency: first/last versus front/back

[clarfonthey]

All of the collections in the former collections crate use the front/back naming convention, but slice uses a first/last naming convention. I doubt that deprecating the former is a good idea at this rate, but it's worth talking about— should the methods first/last, first/last_mut, split_first/last be renamed to front/back, or should it go the other way?

[kennytm]

Iterator also uses last; meanwhile DoubleEndedIterator has next_back.

[strega-nil]

I'm quite curious of people's opinion on this.

In any case, other languages:

• C++: front/back
• Python: none
• Ruby: first/last
• Java: none
• Go: none
• Haskell: head/last
• Idris: head/last

so... I dunno.

[strega-nil]

I think I prefer doubling down on front/back, but I also have some amount of C++ influence.

[Ixrec]

I like front/back slightly better because they naturally extend to other APIs like next_back where you need to specify just a "direction" and not an "endpoint" the way first/last do.

I am mostly influenced by C++ and Javascript, though I'm not about to suggest the latter because it's kind of insane on this issue:

• Javascript: (un)shift / none

[bluss]

C++ names are lovely, but my standard is that the names must be actively harmful to correctness of programs or harmful to adoption of Rust to warrant renaming of oft-used API. (And this does not seem to reach that level.)

[scottmcm]

Hmm, in C++ v.push_back(x) and v.insert(v.end(), x) are synonyms, but don't use the same word either.

I wonder whether there's a consistent (and possibly useful) interpretation here where first and last are elements, whereas front and back are insertion points (aka fenceposts, like "past-the-end" in C++).

[strega-nil]

@bluss I mean, it's just slice that uses first/last; collections uses front/back. That's the issue, the inconsistency is confusing.