Add flatmap_over_map_reduce opt-in rule

[marcelofabri]

Fixes #2883

[SwiftLintBot]

	12 Messages
📖	Linting Aerial with this PR took 3.84s vs 3.75s on master (2% slower)
📖	Linting Alamofire with this PR took 8.21s vs 7.34s on master (11% slower)
📖	Linting Firefox with this PR took 19.66s vs 17.7s on master (11% slower)
📖	Linting Kickstarter with this PR took 46.32s vs 33.17s on master (39% slower)
📖	Linting Moya with this PR took 3.29s vs 2.9s on master (13% slower)
📖	Linting Nimble with this PR took 2.66s vs 2.65s on master (0% slower)
📖	Linting Quick with this PR took 1.02s vs 1.07s on master (4% faster)
📖	Linting Realm with this PR took 5.57s vs 6.06s on master (8% faster)
📖	Linting SourceKitten with this PR took 1.86s vs 2.08s on master (10% faster)
📖	Linting Sourcery with this PR took 6.05s vs 6.02s on master (0% slower)
📖	Linting Swift with this PR took 47.76s vs 39.71s on master (20% slower)
📖	Linting WordPress with this PR took 36.72s vs 39.19s on master (6% faster)

Generated by 🚫 Danger

[jpsim]

Why opt-in?

[jpsim]

Also, isn't curious that nothing in OSSCheck triggered this?

[marcelofabri]

Why opt-in?

The other similar rules are opt-in. In theory there could be a type that implements map but not flatMap

[jpsim]

Can this support the reduce(into:) variant?

[marcelofabri]

Can this support the reduce(into:) variant?

it could, but it's more complicated because we need to analyze the closure (although we probably should also do it for the tradicional reduce). I just wanted something quick that would catch the more obvious (and what I thought to be more common) case as this showed up in a PR that I was reviewing today.

[marcelofabri]

Also, isn't curious that nothing in OSSCheck triggered this?

I was able to get a warning on SwiftLint itself by changing

let allPaths = paths.flatMap { $0 }

to

 let allPaths = paths.map { $0 }.reduce([], +)

So I guess this is just not a common issue? Or at least in this form, using + as the parameter.