# SE-0346: Lightweight same-type requirements for primary associated types

**URL:** <https://forums.swift.org/t/se-0346-lightweight-same-type-requirements-for-primary-associated-types/55869>\
**Category:** Proposal Reviews\
**Tags:** generics\
**Created:** [March 11, 2022, 9:01pm UTC](https://forums.swift.org/t/se-0346-lightweight-same-type-requirements-for-primary-associated-types/55869 "2022-03-11T21:01:29Z")\
**Posts on this page:** 1\
**Showing post:** 47

<div class="post-metadata">

**Author:** ![OneSadCookie](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/onesadcookie/32/3205_2.png) [@OneSadCookie](https://forums.swift.org/u/OneSadCookie)\
**Post date:** [March 15, 2022, 1:47am UTC](https://forums.swift.org/t/se-0346-lightweight-same-type-requirements-for-primary-associated-types/55869/47 "2022-03-15T01:47:59Z")

</div>

I think that that response actually helps me understand this proposal more, as:

- the distinction between types and protocols and the constraints they create is already confusing as hell,
- [presuming you agree about multivariable typeclasses getting some unrelated syntax or never existing] this piece of syntax isn't useful for another purpose, and,
- in general, in the positions in which it will be legal, for the protocols where it will see use, it will mean what you would expect, by analogy to a generic type conforming to the protocol

In fact, you basically wouldn't expect to use this for a protocol where an implementing type wouldn't use a generic for this associated type. So if we made OptionalProtocol, Wrapped would be a primary associated type, but eg. CodingKey would never be a primary associated type of Codable.

Am I starting to get it?

---

_[View the full topic](https://forums.swift.org/t/se-0346-lightweight-same-type-requirements-for-primary-associated-types/55869)._