# Generalized opaque and existential type constraints **URL:** \ **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:** 33
**Author:** ![hborla](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/hborla/32/27563_2.png) [@hborla](https://forums.swift.org/u/hborla)\ **Post date:** [February 23, 2022, 9:57pm UTC](https://forums.swift.org/t/generalized-opaque-and-existential-type-constraints/55494/33 "2022-02-23T21:57:59Z")
> [@Philippe\_Hausler](#): > > That exercise means to me that the "primary" generic characteristics are not primary (as in singular) but instead they are "required" generic characteristics. This falls in line with `Publisher` which has two distinct characteristics; the `Output` and the `Failure` . I agree! The "primary associated type" pitch has been updated to support more than one primary associated type. > [@ExFalsoQuodlibet](#): > > I think I got slightly confused by the fact that you mentioned the `Result type parameter clause` option in the original post, which I read as a way to put in the same ballpark the opaque syntax and the "reverse generics" one, like they were 2 possible options to achieve the same goal. Yes, the "result type parameter clause" idea is a more general version of opaque result types, i.e. "reverse generics". Arbitrary constraints are already possible for opaque types in parameter position by using explicit type parameters, so I intended for this discussion to be focused on opaque result types, specifically. > [@ExFalsoQuodlibet](#): > > This wouldn't allow to express cross-parameter constraints, but we should then understand what level of generality we want for this before going back to explicit type parameters. Personally, I think the level of generality before moving to explicit type parameters in angle brackets should be exactly what's in the primary associated type pitch. Of course, others might disagree 🙂 I explained why I think that's the case in my post here: > [@\[Pitch 2\] Light-weight same-type requirement syntax](https://forums.swift.org/t/pitch-2-light-weight-same-type-requirement-syntax/55081/133): > > Thank you for pointing this out - I think this is a good observation. I completely agree that evolving a generic signature from the sugared form to the more expressive form is important, and this will become a crucial part of the learning curve for concepts like type parameters and associated types. The need to transform a signature when adding associated type requirements is an inherent problem introduced by the opaque parameters feature that was just accepted. I don't think that's a bad thin… And John's post here explains the "grand vision" in more detail: > [@\[Pitch 2\] Light-weight same-type requirement syntax](https://forums.swift.org/t/pitch-2-light-weight-same-type-requirement-syntax/55081/153): > > Holly has covered this to a significant degree, but let me try to lay out the grand vision for where this is going. We have an opportunity for a synthesis across several different language features: We'd like generics to have stronger language connections to other things so that picking up generic programming feels more familiar, with better progressive disclosure of complexity. We'd like to be able to express more advanced constraints on existential types (protocol and protocol composition t… --- _[View the full topic](https://forums.swift.org/t/generalized-opaque-and-existential-type-constraints/55494)._