# \[Accepted\] SE-0352: Implicitly Opened Existentials

**URL:** <https://forums.swift.org/t/accepted-se-0352-implicitly-opened-existentials/57553>\
**Category:** Announcements\
**Created:** [May 24, 2022, 8:41pm UTC](https://forums.swift.org/t/accepted-se-0352-implicitly-opened-existentials/57553 "2022-05-24T20:41:22Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Joe\_Groff](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/joe_groff/32/1929_2.png) [@Joe\_Groff](https://forums.swift.org/u/Joe_Groff)\
**Post date:** [May 24, 2022, 8:41pm UTC](https://forums.swift.org/t/accepted-se-0352-implicitly-opened-existentials/57553/1 "2022-05-24T20:41:22Z")

</div>

Hi everyone. The [second review](https://forums.swift.org/t/se-0352-second-review-implicitly-opened-existentials/56878) of [_SE-0352: Implicitly Opened Existentials_](https://github.com/apple/swift-evolution/blob/main/proposals/0352-implicit-open-existentials.md) completed on May 18, 2022, and the core team has decided to **accept** the proposal. This second review focused on forward compatibility concerns when the return type of a call involving an implicitly-opened existential has to be type-erased to keep the dynamic type of the existential from leaking into the return type. As the expressivity of existentials increases, we may be able to use a more specific type as the return type of such a call, which could create source breaks. To avoid this, the proposal required an explicit `as any P` type annotation on calls where the return type that can be expressed today would discard constraints on the original associated type being type-erased, as in the example from the proposal:

```swift
protocol P {
  associatedtype A
}
protocol Q {
  associatedtype B: P where B.A == Int
}

func getP<T: P>(_ p: T)
func getBFromQ<T: Q>(_ q: T) -> T.B { ... }

func eraseQAssoc(q: any Q) {
  let x = getBFromQ(q) // error, must specify "as any P" due to loss of constraint T.B.A == Int
  let y = getBFromQ(q) as any P // ok, explicitly throws away constraint
}

```

During review, an issue was raised with this design that it becomes ambiguous when a call like this is used as the argument to another call, since `as any P` is also the syntax for suppressing implicit opening of an existential. In response, the authors revised the proposal to document this ambiguity, and explicitly specify that using parentheses prevents the "suppress implicit opening" meaning from taking effect:

```swift
protocol P {
  associatedtype A
}
protocol Q {
  associatedtype B: P where B.A == Int
}

func getP<T: P>(_ p: T)
func getBFromQ<T: Q>(_ q: T) -> T.B { ... }
func eraseQAssoc(q: any Q) {
  getP(getBFromQ(q)) // error, must specify "as any P" due to loss of constraint T.B.A == Int
  getP(getBFromQ(q) as any P) // suppresses error above, but also suppresses opening, so it produces
                              // error: now "any P does not conform to P" and op
  getP((getBFromQ(q) as any P)) // okay! original error message should suggest this
}

```

The core team has accepted these amendments to the original proposal, and the community response was positive as well. Thank you to everyone who participated in both rounds of review!

---

<div class="post-metadata">

**Author:** ![stephencelis](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/stephencelis/32/2675_2.png) [@stephencelis](https://forums.swift.org/u/stephencelis)\
**Post date:** [June 24, 2022, 2:37pm UTC](https://forums.swift.org/t/accepted-se-0352-implicitly-opened-existentials/57553/2 "2022-06-24T14:37:44Z")

</div>

Should this behavior be available in Xcode 14 beta 2, or is its version of Swift 5.7 still lagging? I can't seem to pass existentials to functions that take the generic equivalent yet.

Edit: Ah, it actually _does_ seem to work, just not in playgrounds. I guess playgrounds somehow don't support this feature yet? Filed [FB10447228](https://gist.github.com/mbrandonw/abb100582061fa16c7f7fcebb7927b3a).