<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Hi Matthew,</div><div class="gmail_quote"><br></div><div class="gmail_quote">Thank you for putting together this list. I will be answering from the standard library perspective.</div><div class="gmail_quote"><br></div><div class="gmail_quote">On Tue, Dec 15, 2015 at 7:25 PM, Matthew Johnson via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote: <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div></div><div>- ** generic typealias</div></div></div></blockquote><div><br></div><div>I don't know of a usecase in the standard library.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div>- allow protocols to specify a non-covarying Self in static method declarations (a possible solution to the problem of conforming non-final classes in Cocoa to protocols containing factory methods)</div></div></div></blockquote><div><br></div><div>I don't know of a usecase in the standard library.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div></div><div>- extensions</div><div><span style="white-space:pre-wrap"> </span>- ** allow same type constraints</div><div><span style="white-space:pre-wrap"> </span>- ** allow protocol conformance in constrained extensions</div><div><span style="white-space:pre-wrap"> </span>- allow protocol conformance in protocol extensions</div></div></div></blockquote><div><br></div><div>Yes, the standard library needs all of these.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div>- associated type constraints</div><div><span style="white-space:pre-wrap"> </span>- use of Self as a superclass constraint</div><div><span style="white-space:pre-wrap"> </span>- ** where clause constraining inidividual associated types</div><div><span style="white-space:pre-wrap"> </span>- ** where clause relating multiple assocated types</div></div></div></blockquote><div><br></div><div>The standard library needs the 'where' clauses, but not the 'Self' superclass constraint.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div>- existentials for protocols with associated types</div><div><span style="white-space:pre-wrap"> </span>- protocol existentials don't conform to the protocol itself</div><div><span style="white-space:pre-wrap"> </span>- ** fully bound: protocol<GeneratorType where Element == Int> </div><div><span style="white-space:pre-wrap"> </span>- ** fully constrained: protocol<GeneratorType where Element: CustomStringConvertible></div><div><span style="white-space:pre-wrap"> </span>- partially bound / constrained - allow access to members only mentioning constrained associated types</div><div><span style="white-space:pre-wrap"> </span>- ** unbound - allow access to members not mentioning Self or associated types</div><div><span style="white-space:pre-wrap"> </span>- composition: protocol<P1, P2 where P1.Associated: P3, P2.Associated == Int, P1.Other == P2.Other></div></div></div></blockquote><div><br></div><div>Depending on the details, this might replace AnySequence / AnyCollection.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div></div><div>- nesting (per Slava's email)</div><div><span style="white-space:pre-wrap"> </span>- ** Generic types nested inside generic functions</div><div><span style="white-space:pre-wrap"> </span>- ** Generic types nested inside generic types</div><div><span style="white-space:pre-wrap"> </span>- ** Generic functions nested inside generic functions which capture values or outer generic types</div></div></div></blockquote><div><br></div><div>The standard library needs generic types nested inside generic types to move types from the top level, like moving DictionaryIndex into Dictionary.</div><div><br></div><div>Another thing that we need is recursive associated type constraints:</div><div><br></div><div>protocol CollectionType {</div><div> typealias SubSequence : CollectionType</div><div>}<br></div><div><br></div><div>Dmitri</div><div><br></div></div>-- <br><div class="gmail_signature">main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if<br>(j){printf("%d\n",i);}}} /*Dmitri Gribenko <<a href="mailto:gribozavr@gmail.com" target="_blank">gribozavr@gmail.com</a>>*/</div>
</div></div>