[Pitch] Primary Associated Types in the Standard Library

[Douglas_Gregor]

Excited to see this!

@lorentey

LazySequenceProtocol and LazyCollectionProtocol use Elements as their primary associated type, not Element . The idea here is that if we spell out LazyCollectionProtocol , we probably want to also say something about the wrapped collection, not just its element type -- for example, by constraining it to random access collections using some LazyCollectionProtocol<some RandomAccessCollection<String>> .

Personally, I'd rather we not add any primary associated types to LazySequenceProtocol and LazyCollectionProtocol. They aren't likely to be used often, and it feels odd to have them be based on Elements rather than Element like the other sequence/collection protocols. We could always add them later if compelling use cases show up in sufficient quantity.

@lorentey

Feedback would be most appreciated -- did I miss anything?

The distributed actors runtime proposal added a few protocols that could benefit from this feature. @ktoso should weigh in here as well, but my take is:

• DistributedActor<ActorSystem>
• DistributedActorSystem<SerializationRequirement>: this protocol has several associated types, but I anticipate any DistributedActorSystem<Codable> to be a Very Useful Thing.
• DistributedTargetInvocationEncoder<SerializationRequirement>
• DistributedTargetInvocationDecoder<SerializationRequirement>
• DistributedTargetInvocationResultHandler<SerializationRequirement>

@lorentey

AsyncSequence and AsyncIteratorProtocol are intentional omissions -- given that there are ongoing discussions about adding an Error type to these, it seems prudent to leave these out until we know more. (Per SE-0346 , adding Error as a second primary would be a source-breaking change.)

Definitely the right call. We should bring this in when we've dealt with the Error type, rethrowing conformances, and all of the other exciting throwing-ness of these protocols.

Doug