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

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?

6 Likes