<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="">One of the big things that bugs me about working with protocols and generics is that they have a fundamentally different style to working with generics on structs and classes. While has some minor benefits on differentiating them, I think that overall it results in inconsistency that makes them harder to work with.<div class=""><br class=""></div><div class="">I’d like to propose two fairly minor changes that allow protocols to be defined using angle brackets for generics to make things much easier. </div><div class=""><br class=""></div><div class="">First is allowing a protocol to be defined using angle brackets for its generic type(s) like so:</div><div class=""><br class=""></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>protocol FooType<Element, Index:ForwardIndexType> {</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>func getElement(atIndex:Index) -> Element?</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>}</font></div><div class=""><br class=""></div><div class="">In this example the protocol Foo has implicit type aliases for Element and Index, which can be fulfilled like so:</div><div class=""><br class=""></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>struct Foo<Element> : FooType<Element, Int> {</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>func getElement(atIndex:Index) -> Element? { … }</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>}</font></div><div class=""><br class=""></div><div class="">The other important case is defining type constraints with protocol generics, currently we have to do stuff like this:</div><div class=""><br class=""></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>func append<S:SequenceType where S.Generator.Element == Element>(contentsOf theSequence:S) { … }</font></div><div class=""><br class=""></div><div class="">However, while definition with a where clause is powerful, in the majority of cases it’s much more complex than it needs to be. So I’d like to propose that we can have the following:</div><div class=""><br class=""></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>protocol SequenceType<Element> { … }</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>func append(contentsOf theSequence:SequenceType<Element>) { … }</font></div><div class=""><br class=""></div><div class="">Behind the scenes these may be unwrapped into type aliases and where clauses like we have now, but for the developers this is much, much simpler to work with, especially when most generic constraints are pretty simple.</div><div class=""><br class=""></div><div class="">I’m not proposing the removal of where clauses as they can be really useful in more unusual cases, so will still have utility there. I’m not so sure about explicit type alias declaration like we have now though; using the angle brackets to declare these seems just as capable to me unless there are some cases I haven’t considered.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">This seems like something that may have been discussed in the past, but I’m not that great on specific terminology for features (I’m not as well versed as others are on the correct names for language features) so I haven’t found anything, but fully expect that I may have missed it somehow, in which case a link would be appreciated.</div><div class=""><br class=""></div><div class="">But if no proposal currently exists then I’d love to know, as I could try to create a more formal proposal for this if necessary, as I know that I for one would benefit greatly from simplified protocol generics, as they’re currently one of my least favourite features to use syntactically, but one I need to use a lot.</div></body></html>