<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On Apr 12, 2016, at 11:19 PM, David Hart &lt;<a href="mailto:david@hartbit.com" class="">david@hartbit.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class="">Hi Doug,</div><div class=""><br class=""></div><div class="">I've read the discussion about moving the where clause to the right of declarations (which I full-heartedly approve) but I don't see how it would have any impact on the syntax of associated types requirements.<br class=""></div></div></div></blockquote><div><br class=""></div><div>I think “arbitrary requirements in protocols” doesn’t necessarily require them to be attached to an associated type. For example, Collection might require that the SubSequence type itself be a Collection:</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre">        </span>protocol Collection : Sequence {</div><div><span class="Apple-tab-span" style="white-space:pre">        </span>&nbsp; associatedtype SubSequence : Collection</div><div><span class="Apple-tab-span" style="white-space:pre">        </span>}&nbsp;</div><div><br class=""></div><div>Why did we have to declare the SubSequence associated type again (since it’s already down in SubSequence) just to make it conform to Collection. In fact, why are we even allowed to declare a redundant associated type, which we know is defined in Sequence and will have to be the same? Seems to me that we just want a where clause to add the constraint, e.g.,</div><div><br class=""></div><div><div><span class="Apple-tab-span" style="white-space: pre;">        </span>protocol Collection : Sequence {</div><div><span class="Apple-tab-span" style="white-space: pre;">        </span>&nbsp; where SubSequence : Collection</div><div><span class="Apple-tab-span" style="white-space: pre;">        </span>}&nbsp;</div><div class=""><br class=""></div><div class="">which of course would conflict with moving where clauses later, e.g.,</div><div class=""><br class=""></div><div class=""><div><span class="Apple-tab-span" style="white-space: pre;">        </span>protocol Collection : Sequence {</div><div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; func foo() // is the following where clause part of foo() or part of Collection?</div><div><span class="Apple-tab-span" style="white-space: pre;">        </span>&nbsp; where SubSequence : Collection</div><div><span class="Apple-tab-span" style="white-space: pre;">        </span>}&nbsp;</div></div><div class=""><br class=""></div><div class=""><br class=""></div></div><div><span class="Apple-tab-span" style="white-space:pre">        </span>- Doug</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><div class=""><br class=""></div><div class="">David</div><div class=""><br class="">On 12 Apr 2016, at 19:07, Douglas Gregor via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Apr 11, 2016, at 1:01 AM, Jacob Bandes-Storch via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Doug wrote this in the Completing Generics manifesto, under "Minor extensions":<div class=""><br class=""></div><div class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><i class="">*Arbitrary requirements in protocols<br class=""></i></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">&nbsp;</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Currently, a new protocol can inherit from other protocols, introduce new associated types, and add new conformance constraints to associated types (by redeclaring an associated type from an inherited protocol). However, one cannot express more general constraints. Building on the example from “Recursive protocol constraints”, we really want the element type of a Sequence’s SubSequence to be the same as the element type of the Sequence, e.g.,<br class=""></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">&nbsp;</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">&nbsp; &nbsp; protocol Sequence {<br class="">&nbsp; &nbsp; &nbsp; &nbsp; associatedtype Iterator : IteratorProtocol<br class="">&nbsp; &nbsp; &nbsp; &nbsp; …<br class="">&nbsp; &nbsp; &nbsp; &nbsp; associatedtype SubSequence : Sequence where SubSequence.Iterator.Element == Iterator.Element<br class="">&nbsp; &nbsp; }<br class=""></blockquote><div class=""><br class=""></div><div class=""><br class=""></div><div class="">+1.</div><div class=""><br class=""></div><div class="">To make it into Swift 3, would this feature require a proposal of its own? </div></div></div></div></blockquote><div class=""><br class=""></div><div class="">Yes. Also, be wary that the syntax above potentially conflicts with the syntax discussed as "moving the where clauses”:</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre">        </span><a href="http://thread.gmane.org/gmane.comp.lang.swift.evolution/13886/focus=14058" class="">http://thread.gmane.org/gmane.comp.lang.swift.evolution/13886/focus=14058</a></div><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class="">How feasible would it be to implement on top of the current system?</div></div></div></div></blockquote><br class=""></div><div class="">Definitely! The archetype builder would need to learn to check these extra where clauses, and one would need to be sure that the constraint solver is picking them up as well.</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre">        </span>- Doug</div><div class=""><br class=""></div><br class=""></div></blockquote><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote></div></div></blockquote></div><br class=""></body></html>