# Suggestion: Don't allow closure parameters to shadow types

**URL:** <https://forums.swift.org/t/suggestion-dont-allow-closure-parameters-to-shadow-types/31639>\
**Category:** Discussion\
**Created:** [December 13, 2019, 6:44am UTC](https://forums.swift.org/t/suggestion-dont-allow-closure-parameters-to-shadow-types/31639 "2019-12-13T06:44:51Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![tapthaker](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/tapthaker/32/3800_2.png) [@tapthaker](https://forums.swift.org/u/tapthaker)\
**Post date:** [December 13, 2019, 6:44am UTC](https://forums.swift.org/t/suggestion-dont-allow-closure-parameters-to-shadow-types/31639/1 "2019-12-13T06:44:51Z")

</div>

**Context:**  
We can currently declare a closure with its parameters as just types. An exception to this rule is for sugared types where the swift compiler will throw an error,  
e.g. :

```swift
  struct Bar {}
  struct Foo {
    func registerCallback(_ callback: @escaping ([Bar]) -> Void) {}
    func registerCallback(_ callback: @escaping (Bar?) -> Void) {}
  }

// Call_1
  Foo().registerCallback { (_ : [Bar]) in } // OK
// Call_2
  Foo().registerCallback { ([Bar]) in } // expected-warning {{unnamed parameters must be written with the empty name '_'}} {{29-29=_: }}
// Call_3
  Foo().registerCallback { (_: Bar?) in } // OK
// Call_4
  Foo().registerCallback { (Bar?) in } // expected-error {{unnamed parameters must be written with the empty name '_'}}

```

As for the cause of a hard-failure for sugared types _(Call\_4)_, it is is because there was a bug in the parsing logic which we later on fixed it with proper diagnostics in [PR#28315](https://github.com/apple/swift/pull/28315)

As per my discussion with @codafi, closure declaration is allowed to shadow types because it's an oversight in the logic we use for parsing parameters. And that it was never the intent.

**Question:**  
Given that we never intended this behavior in the closure declarations, how does the community feel about erroring in those situations _(Call\_2)_? Please bear in mind this change will be source-breaking.