<div dir="ltr">That seems reasonable. Onward ho!</div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, May 8, 2016 at 3:46 PM, David Hart <span dir="ltr">&lt;<a href="mailto:david@hartbit.com" target="_blank">david@hartbit.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><span class=""><br><div><blockquote type="cite"><div>On 09 May 2016, at 00:38, Austin Zheng &lt;<a href="mailto:austinzheng@gmail.com" target="_blank">austinzheng@gmail.com</a>&gt; wrote:</div><br><div><span style="font-family:Helvetica;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">Is the plan to eventually support &quot;multiple&quot; forms of concrete same-type requirement syntax - the existing &quot;where Element == SomeConcreteType&quot; and the generic parameterized extensions described elsewhere? If not, the syntax should probably be discussed as part of a pre-proposal thread before anything else happens.</span></div></blockquote></div><br></span><div>The way modifications have gone through swift-evolution, it seems like it would be more logical to implement it with no syntax change first and only then propose and discuss generic parameterised extensions.</div></div></blockquote></div><br></div>