Decide which methods to add to new Range types

[traviscross]

There's been discussion on the tracking issue:

• Tracking Issue for RFC 3550: New range types #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

[pitaj]

This is strictly about what inherent methods we want to copy from Iterator onto the new range types. Anything else that can be implemented on the existing range types should go through the ACP process