# SE-0286: Forward Scan for Trailing Closures

**URL:** <https://forums.swift.org/t/se-0286-forward-scan-for-trailing-closures/38529>\
**Category:** Proposal Reviews\
**Created:** [July 17, 2020, 6:44pm UTC](https://forums.swift.org/t/se-0286-forward-scan-for-trailing-closures/38529 "2020-07-17T18:44:05Z")\
**Posts on this page:** 1\
**Showing post:** 43

<div class="post-metadata">

**Author:** ![Douglas\_Gregor](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/douglas_gregor/32/1362_2.png) [@Douglas\_Gregor](https://forums.swift.org/u/Douglas_Gregor)\
**Post date:** [July 24, 2020, 8:31pm UTC](https://forums.swift.org/t/se-0286-forward-scan-for-trailing-closures/38529/43 "2020-07-24T20:31:15Z")

</div>

> [@Jumhyn](#):
>
> Why do we still need the heuristic? Shouldn't attempting both the forward scan _and_ the backward scan (and preferring the backward scan in ambiguous cases) be sufficient for source compatibility?

This proposal needs to put us at a good "resting place" both for Swift 5.3+ and Swift 6. The heuristic makes the forward scan work for enough existing APIs that I don't feel like we can simply drop it from Swift 6 without a suitable replacement. For example, I call out this SwiftUI example in the proposal:

```swift
func sheet(
  isPresented: Binding<Bool>,
  onDismiss: (() -> Void)? = nil,
  content: @escaping () -> Content
) -> some View

```

The intent here is clear: the unlabeled trailing closure is supposed to be `content`, because the SwiftUI DSL is formulated that way. If we take away the heuristic but don't have some way to indicate SwiftUI's intent, we have a source break without a good path forward for developers. Of course, a proposal along the lines of what's mentioned in "Future directions" of the proposal could absolutely revoke the heuristic from some future Swift version (be it Swift 6 or later), but it needs to do so with full consideration of the source compatibility impact and the need to support API developers. We can't assume that such a proposal will come along and be accepted in time; SE-0286 has to leave the language in a good place for all of the language versions it touches (Swift 5.3+ and Swift 6+).

SwiftUI isn't an outlier here; I saw a number of examples when I did a [source compatibility run](https://github.com/apple/swift/pull/33069) with the forward+backward scan but _without_ the heuristic (I had the same thought as you).

Doug

---

_[View the full topic](https://forums.swift.org/t/se-0286-forward-scan-for-trailing-closures/38529)._