Add rule to prefer opaque generic parameter syntax

[calda]

Summary

This PR proposes a rule to prefer opaque generic parameter syntax (using some) over the more-verbose named generic parameter syntax where equivalent.

// WRONG
func spaceshipDashboard<WarpDriveView: View, CaptainsLogView: View>(
  warpDrive: WarpDriveView,
  captainsLog: CaptainsLogView)
  -> some View
{ … }

func generate<Planets>(_ planets: Planets) where Planets: Collection, Planets.Element == Planet {
  …
}

// RIGHT
func spaceshipDashboard(
  warpDrive: some View,
  captainsLog: some View)
  -> some View
{ … }

func generate(_ planets: some Collection<Planet>) {
  …
}

Reasoning

We are adopting Swift 5.7 soon, so we should adopt guidance for its new language features.

Opaque generic parameter syntax is significantly less verbose and thus more legible than the full named generic parameter syntax. Auto-formatting for this rule is implemented in nicklockwood/SwiftFormat#1206.

some Any

Fully-unconstrained generic parameters are somewhat uncommon, but are equivalent to some Any. For example:

func assertFailure<Value>(_ result: Result<Value, Error>) {
  if case .failure(let error) = result {
    XCTFail(error.localizedDescription)
  }
}

// is equivalent to:
func assertFailure(_ result: Result<some Any, Error>) {
  if case .failure(let error) = result {
    XCTFail(error.localizedDescription)
  }
}

some Any is somewhat unintuitive, and the named generic parameter is useful in this situation to compensate for the weak type information. Because of this, prefer using named generic parameters instead of some Any.

With --someAny disabled (nicklockwood/SwiftFormat#1261), the SwiftFormat rule never automatically converts generic functions to use some Any. This isn't outright banned, however, since we don't have an auto-formatting implementation that converts some Any to named generic parameter syntax.

Please react with 👍/👎 if you agree or disagree with this proposal.

[erichoracek]

Nice! Just one small suggestion

[bachand]

My understanding is that we'd discourage writing an XCTest helper like this since then we would lose the file/line number of the failure (@fdiaz ). I wonder if we can come up with another example.

[calda]

I pulled this example from the apps repo -- its sort of hard to come up with an example use case of a totally unconstrained generic parameter that doesn't feel contrived. Open to other suggestions though!

[bachand]

I agree that this is a good example so that I updated it to pass through the file and line: #204

[bachand]

Link to proposal in case it's helpful: https://github.com/apple/swift-evolution/blob/main/proposals/0341-opaque-parameters.md