Configuration option for auto-rewrite of trailing closures

[woolsweater]

Description

Context

Change #1072 introduced automatic expansion of trailing closures. For example, when requesting completion for a call to the function func foo(bar: Bar, baz: @escaping () -> Void) sourcekit-lsp manipulates the function template to produce this (using Xcode placeholder syntax to avoid confusion with closure shorthand args):

foo(bar: <#Bar#>) {
  <#Void#>
}

While this multi-line expansion may be appropriate for callback-based (Timer.scheduledTimer) or scope-defining (DispatchQueue.async, String.withUTF8) functions, it is strictly worse in my opinion for simple predicate-based calls. Consider someArray.filter: this expands to three lines with two placeholders:

someArray.filter { <#Foo#> in
  <#Bool#>
}

But more often than not I was just going to type a short single-line expression like someArray.filter { $0.bar() == baz }, or even to use a key path: someArray.map(\.bar). Even for a callback it is not uncommon to use a named function reference rather than a literal: foo(bar: someBar, baz: handleBaz).

It is much more work now to correct the multi-line expanded form to the shorter version than it was to expand a callback-based method from foo(bar: <#Bar#>, <#() -> Void#>).

Proposed Change

Whether to expand trailing closures at all, let alone to multiple lines, is largely a stylistic decision; as such the language server should permit user control over it. A field should be added to the configuration options allowing this feature to be turned off (and, perhaps, to allow reducing its intensity: cf. #1788).

[ahoppen]

Synced to Apple’s issue tracker as rdar://138732061

[ahoppen]

As discussed in #1789, we don’t want a configuration option here at the moment and you implemented a great middle-ground solution in #1831. So let’s close this issue.