Rule Request: Closure Parameter Count

New Issue Checklist

• Updated SwiftLint to the latest version
• I searched for existing GitHub issues

New Rule Request

function_parameter_count limits arity for function and method declarations, but there is no equivalent for closures.

The original request that produced that rule, #415, asked for a warning on methods/functions/closures with too many parameters. The implementation only visits FunctionDeclSyntax (FunctionParameterCountRule), so closure expressions, trailing closures, and closure type signatures are never counted.

High-arity closures have the same readability problem as high-arity functions (call sites and bodies are hard to follow; “introduce parameter object” still applies), and they are easy to miss because $0…$n does not look like a long parameter list.

Related existing rules cover position, unused names, and body length (closure_parameter_position, unused_closure_parameter, closure_body_length), not count.

1. Why should this rule be added?

Same rationale as function_parameter_count: a large parameter list is a complexity smell. Closures are a gap in that metric.

Community / prior discussion:

• #415 (“Limit number of method/closure parameters rule”) — implemented for functions only; inits later excluded
• #4217 (constructor parameter count) — similar arity metric, still open; this request is the closure side of the same idea

2. Examples

Assume a warning threshold of 5 (matching function_parameter_count defaults).

Would not trigger:

let sum = numbers.reduce(0) { $0 + $1 }

items.enumerated().map { index, item in
    (index, item)
}

let handler: (Int, Int, Int) -> Void = { a, b, c in
    print(a, b, c)
}

// Capture list is not a parameter list
{ [weak self, unowned delegate] value in
    self?.handle(value, delegate)
}

Would trigger:

↓{ a, b, c, d, e, f in
    a + b + c + d + e + f
}

items.combine { ↓a, b, c, d, e, f in
    (a, b, c, d, e, f)
}

// Shorthand: highest index implies 6 parameters
_ = values.map { ↓$0 + $1 + $2 + $3 + $4 + $5 }

let handler: ↓(Int, Int, Int, Int, Int, Int) -> Void

3. Configuration

Mirror function_parameter_count:

• warning / error severity thresholds (suggested defaults: warning 5, error 8)
• Whether unused _ parameters count (suggest yes: they still contribute arity)
• Whether shorthand $n counts as n + 1 parameters (suggest yes)
• Whether closure type signatures (e.g. (A, B, C, D, E, F) -> R) are included, or only closure expressions (could be a boolean, defaulting to expressions only if type-signature noise is a concern)
• Capture-list items should not count

4. Opt-in or enabled by default?

Opt-in. Apple and third-party APIs often use high-arity callbacks; enabling this by default would be noisy in a way function_parameter_count is not. Projects that already care about function arity can turn it on independently (and with its own thresholds).

Start by reading the existing FunctionParameterCountRule implementation and the related closure rules, including closure_parameter_position, unused_closure_parameter, and closure_body_length. Then inspect their syntax visitors, configuration, and tests to determine how closure expressions and shorthand parameters are represented. Done means an opt-in closure arity rule with documented threshold behavior and coverage for the examples and configuration choices in this issue.