# Lifting the "Self or associated type" constraint on existentials

**URL:** <https://forums.swift.org/t/lifting-the-self-or-associated-type-constraint-on-existentials/18025>\
**Category:** Pitches\
**Created:** [November 15, 2018, 10:13pm UTC](https://forums.swift.org/t/lifting-the-self-or-associated-type-constraint-on-existentials/18025 "2018-11-15T22:13:59Z")\
**Posts on this page:** 1\
**Showing post:** 113

<div class="post-metadata">

**Author:** ![xwu](https://avatars.discourse-cdn.com/v4/letter/x/b487fb/32.png) [@xwu](https://forums.swift.org/u/xwu)\
**Post date:** [November 30, 2018, 7:51pm UTC](https://forums.swift.org/t/lifting-the-self-or-associated-type-constraint-on-existentials/18025/113 "2018-11-30T19:51:37Z")

</div>

Here is a good example of a genuine use case where our current restriction would have saved some confusion if the protocol in question had Self or associated type requirements:

> [@Pattern matching Errors](https://forums.swift.org/t/pattern-matching-errors/18452):
>
> I ran into some strange behavior while testing pattern matching in catch blocks: protocol FooError : Error { func whatWentWrong() -\> String } extension Array : FooError, Error where Element: FooError { func whatWentWrong() -\> String { return "idk i'm an array" } } struct MyError : FooError { func whatWentWrong() -\> String { return "something happened" } } func test() throws { throw [MyError()] } do { try test() } catch let err where err is [FooError] { // Why is this n…

---

_[View the full topic](https://forums.swift.org/t/lifting-the-self-or-associated-type-constraint-on-existentials/18025)._