ACP: add `str::version_cmp`

Proposal

Problem statement

"version sorting" as defined by the rust style guide is a broadly useful operation, and using it instead of lexicographic sorting is usually one of the first things done to improve a program's user-friendlyness.

Motivating examples or use cases

This operation is currently used in many places throughout the project, and currently that is done by copy-pasting the implementation all over, leading to inconsistencies.

This is not just useful within the project, though, pretty much anything that wants to present a sorted list of strings would benefit from this, from file browsers, irc clients, email clients, text editors, static site generators, command-line argument parsers (to sort the autogenerated helptext) and even games (for inventories).

Solution sketch

impl str {
  fn version_cmp(&self, other: &str) -> std::cmp::Ordering;
}

Alternatives

• More complicated and configurable system. I don't think most users will care about what exact sorting is used, and the few that do (such as those within the project) only care that it is the sorting defined in the style guide.
• Publish as a standalone crate. I don't think a function that is well under 200 LoC needs to be split off like this, we don't need another cfg-if.
• Also include a utility function <&mut [impl AsRef<&str>]>::version_sort instead of requiring user to call sort_by.
• Better name that doesn't imply an overly narrow usecase.

Links and related work

• https://github.com/rust-lang/rust/issues/151934, the issue that inspired this ACP
• https://github.com/rust-lang/rust/issues/115585, cfg-select (formerly cfg-match), for precedence on including small utilities like this in the stdlib over having them be separate crates.

Additional Notes

I couldn't find a popular implementation of this on crates.io, which suggests either:

• Most people using version sorting are rolling their own implementation
• People aren't using version sorting in situations where it would make sense due to not wanting to add another dependency
• I didn't look hard enough

Hopefully adding this to the standard library would result in more people using version sorting where applicable, and thus higher quality Rust software in general.

What happens now?

This issue contains an API change proposal (or ACP) and is part of the libs-api team feature lifecycle. Once this issue is filed, the libs-api team will review open proposals as capability becomes available. Current response times do not have a clear estimate, but may be up to several months.

Possible responses

The libs team may respond in various different ways. First, the team will consider the problem (this doesn't require any concrete solution or alternatives to have been proposed):

• We think this problem seems worth solving, and the standard library might be the right place to solve it.
• We think that this probably doesn't belong in the standard library.

Second, if there's a concrete solution:

• We think this specific solution looks roughly right, approved, you or someone else should implement this. (Further review will still happen on the subsequent implementation PR.)
• We're not sure this is the right solution, and the alternatives or other materials don't give us enough information to be sure about that. Here are some questions we have that aren't answered, or rough ideas about alternatives we'd want to see discussed.

Start with the proposal's version-sorting motivation, the Rust style-guide sorting definition, and the linked issues 151934 and 115585. This is an ACP awaiting libs-api review; done means reaching a decision on whether the problem belongs in the standard library and whether the proposed API is appropriate, rather than making a defined code change.