Rule Request: Closure Parameter Count #6901

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:

• Limit number of method/closure parameters rule #415 (“Limit number of method/closure parameters rule”) — implemented for functions only; inits later excluded
• Rule Request: [Constructor Parameters Count] #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).