<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><br class=""><blockquote type="cite" class=""><div class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">It seems like a lot of you are just trying to make different syntaxes for generic protocols, which I’m pretty sure was never the concern about them? We already have reasonable prior art here from the syntax of generic structs.</span></div></blockquote></div><br class=""><div class="">yeah, this discussion has gotten much bigger than I expected:</div><div class="">Just add the common generic-syntax to protocols, and let somebody do the real work ;-).</div><div class=""><br class=""></div><div class="">Stuff like multi-conformance might be useful for some people, but who actually misses it now?</div><div class="">As long as I can write</div><div class="">SomeProtocol<T> instead of creating SomeProtocolInt, SomeProtocolString and SomeProtocolWhatever imho there would already be a huge benefit.</div><div class=""><br class=""></div><div class="">To make things simpler, it would even be feasible to forbid associated types in generic protocols (if this helps):</div><div class="">As soon as associated types are in the mix, I can't create Set<SomeProtocol<T>> (just an example) anymore, so I can turn the parameter into an associated type as well.</div><div class=""><br class=""></div><div class="">- Tino</div></body></html>