Update rule for long function declarations to specify effects (async, throws) should be written on the line after the closing paren

[calda]

Summary

This PR proposes an update to the rule for long function declarations, to specify that effects (async, throws) should be written on the line after the closing paren:

// WRONG
func generateStars(
  at location: Point,
  count: Int,
  color: StarColor,
  withAverageDistance averageDistance: Float) async throws // these effects are easy to miss since they're visually associated with the last parameter
  -> String 
{
  populateUniverse()
}

// RIGHT
func generateStars(
  at location: Point,
  count: Int,
  color: StarColor,
  withAverageDistance averageDistance: Float) 
  async throws -> String 
{
  populateUniverse()
}

This can be auto-formatted using the SwiftFormat --effectsposition wrap option, added in nicklockwood/SwiftFormat#1301.

Reasoning

1. Writing effects on the same line as the closing param makes them easier to miss, since they're visually associated with the last parameter
2. Effects are more closely related to the return type than to the function parameters (e.g. throws -> Universe is effectively syntactic sugar for -> Result<Universe, Error>).

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

[erichoracek]

Does this allow effects to be on the same line if the function is single line? I see other wrap rules have if-multiline

[calda]

Yes, the implementation only wraps the effect if the function params span multiple lines. wrap-if-multiline may be a better name for this option.

[calda]

I updated the option name to --wrapeffects if-mutliline, to match --wrapreturntype if-multiline

[bachand]

Nice comment.

[bachand]

👍