Decide which methods to add to new `Range` types

There's been discussion on the tracking issue:

• https://github.com/rust-lang/rust/issues/123741

...about which methods to add to the new Range types. Let's continue that here.

@orlp said:

To see which iterator methods we may want to add to the new ranges, I did an informal search on Github using the following query:

language:rust NOT is:fork /\W\s*\(\s*\w*\s*\.\.=?\s*\w*\s*\)\s*.\s*method\s*\(/

I matched on anything that looks like ( <> .. <> ) or ( <> ..= <> ) that is not immediately preceded by some identifier character, to avoid matching things like vec.drain(..).map(_).

Example for map: search.

This isn't perfect but captures a rough amount of usage. Just looking by the number of matches:

• map: 65.8k
• rev: 23.2k
• collect: 9.9k
• for_each: 8.5k
• step_by: 8.3k
• filter: 8.2k
• flat_map: 4.2k
• fold: 3.5k
• zip: 3.4k
• filter_map: 1.6k
• find: 1.5k
• chain: 1.4k
• take_while: 1.1k
• all: 1.1k
• cycle: 0.7k
• enumerate: 0.6k
• scan: 0.4k
• product: 0.4k
• find_map: 0.3k
• any: 0.3k
• sum: 0.2k
• take: 0.2k
• skip: 0.1k
• try_*: 0.1k
• min*: 0.1k
• max*: 0.1k
• map_while: 0.1k
• position: 0.1k
• skip_while: 0.1k
• count: 0.1k
• reduce: 0.1k
• nth: 0.1k
• unzip: 0

I personally think filter is a decent cut-off, which gives the inherent methods map, rev, collect, for_each, step_by, filter.

cc @orlp @pitaj @programmerjake

Start with the tracking issue #123741 and review the discussion and GitHub search results quoted here about iterator methods used on range expressions. Done means reaching and documenting a decision about which methods the new Range types should provide.