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

[okaneco]

Would a cartesian_product method be within scope or is this issue strictly about copying methods from Iterator?

Implementing a cartesian_product is my primary use of flat_map on ranges and what I've seen in the wild. Being an inherent method, it might be possible to write a more optimized version in std than a user would naively write as well.

[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