# Generalized opaque and existential type constraints

**URL:** <https://forums.swift.org/t/generalized-opaque-and-existential-type-constraints/55494>\
**Category:** Discussion\
**Created:** [February 22, 2022, 4:11am UTC](https://forums.swift.org/t/generalized-opaque-and-existential-type-constraints/55494 "2022-02-22T04:11:38Z")\
**Posts on this page:** 1\
**Showing post:** 35

<div class="post-metadata">

**Author:** ![bjhomer](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/bjhomer/32/313_2.png) [@bjhomer](https://forums.swift.org/u/bjhomer)\
**Post date:** [March 2, 2022, 6:54am UTC](https://forums.swift.org/t/generalized-opaque-and-existential-type-constraints/55494/35 "2022-03-02T06:54:20Z")

</div>

> [@hborla](#):
>
> I don't think the `some Collection C` syntax covers all use cases for generics. For example, this syntax does not work for generic types with stored properties that reference type parameters for reasons I laid out [in this post](https://forums.swift.org/t/discussion-easing-the-learning-curve-for-introducing-generic-parameters/52891#possible-directions-3), nor does it work for input type parameters in a generic signature that are only used in the result type (which we've determined isn't the best pattern, but it _is_ used in Swift code today)

Okay, I was just thinking in terms of function declarations, but this helped me understand that there's a larger picture here. If I understand correctly, there's a desire to build a syntax for declaring constraints on opaque and existential types _throughout the language_. For the sake of making sure I understand that desire, I'd like to sketch out a few scenarios to make sure I understand.

(I'll use the `some Collection C` syntax as a strawman for now, acknowledging that arguments have been made against it, but I need to use _some_ syntax to illustrate the ideas.)

```swift
// Given this:
protocol Strawman {
  associatedtype Input
}

```

We need a syntax that can be used in all of the following scenarios:

- Function parameters

- Return types

- Stored properties

- Structural return types

- Are there other cases I missed?

As mentioned before, the goal of any syntax proposed here is not to _replace_ the existing `<T>` syntax; rather, we're just trying to find a syntax that allows us to put constraints on `some` and `any` types. Some of the above examples could be written today using regular generics (specifically, examples 1 and maybe 6), but most of the above are currently inexpressible. Likewise, it is not a requirement that everything you can do with generics be expressible via constraints on opaque types.

I'll also note that the "primary associated types" proposal could simplify many of the examples here, but does not replace the need for a general syntax, because a protocol can have many associated types which are _not_ a primary associated type.

* * *

With all of that written out, I'd like some clarification. Many of the suggestions earlier in this thread talk only about opaque result types, but those don't seem like they'd work with existential types. For example, using the "angle brackets after the arrow" syntax, how would you write something that returns a constrained existential type, like `example4` above?

```swift
func whatDoWeDoHere() -> <T> any Strawman where ???

```

Likewise, what would a constrained existential member look like, especially in the case where there may be a naming conflict with an external struct?

```swift
struct S<Input> {
  var x: any Strawman A where A.Input == Input

  // If we don't support naming `any Strawman`, what can you
  // reference in a where clause?
  var y: any Strawman where ???
}

```

It's not clear to me that any other syntax has been proposed which _can_ handle all the use cases suggested above.

---

_[View the full topic](https://forums.swift.org/t/generalized-opaque-and-existential-type-constraints/55494)._