<div dir="ltr">Thanks for the swift response, it&#39;s an honour; I agree wholeheartedly with your logic and sentiment. Sorry if I was unclear, but my concern/curiosity is not for the speed of Swift&#39;s development, but in fact for its long term evolution and longevity. At risk of repeating myself/boring everyone, that concern manifests over two intermingling phenomena:<div><div>1) in the evolution email/proposal archive, a well intentioned (towards -complexity and +quality) but sometimes blasé air around potential uses/requirements of the language (~&quot;Swift won&#39;t support that because people probably wouldn&#39;t use/need it&quot;).</div><div>2) the reality of the clock, or what I think/thought the reality was. Obviously I don&#39;t want Swift to evolve too fast, and don&#39;t think having any particular feature right now is worth risking that, but won&#39;t the ABI be stabilised eventually (Swift 5?) and then it will actually be too late for some features? Please correct me if I&#39;m wrong here.</div><div><br></div><div>A possible (not sure if this is ABI bound) example:</div><div>As far as I&#39;ve seen, optional protocol requirements (like &#39;protected&#39;, private conformances, currying, etc.) are more off the table than postponed, having been deemed an anti-pattern. Fair enough – I&#39;m inclined to trust the people involved in those discussions. But what if after ABI stabilisation people get around to building some significant systems in Swift (say, UIKit, which relies heavily on optional protocol requirements for good reason) and don&#39;t find reasonable alternatives? There&#39;s no going back, right?</div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Aug 4, 2017 at 6:32 PM, Chris Lattner <span dir="ltr">&lt;<a href="mailto:clattner@nondot.org" target="_blank">clattner@nondot.org</a>&gt;</span> wrote:<br><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"><div style="word-wrap:break-word"><br><div><span><blockquote type="cite"><div>On Aug 4, 2017, at 9:16 AM, Mathew Huusko V via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:</div><br class="m_7167906379274664237gmail-m_1969664532381640586m_4138010214411233629Apple-interchange-newline"><div><div dir="ltr">Per <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000233.html" target="_blank">https://lists.swift.org/piperm<wbr>ail/swift-evolution-announce/2<wbr>016-July/000233.html</a>, the removal of parameter labels entirely was accepted as a temporary loss for Swift 3 as a means to remove them from the type system. I&#39;m wondering if they&#39;re coming back (syntactically) any time soon?</div></div></blockquote><div><br></div></span><div>The planning approach for Swift 5 hasn’t been announced yet, but it should be soon-ish.</div><div><br></div><div>Responding to the rest of your email in broad terms: there will always be a ton of things that are important and interesting to tackle.  There is also a long road ahead of Swift, so prioritization is not a bad thing: just because something doesn’t happen “now” doesn’t mean it never will.</div><div><br></div><div>I would also argue that it would be *bad* for the language to evolve too fast.  Landing 20 major features all in the same year runs the very high risk that they doesn’t work well together and don’t have time to settle out properly.  It is far more important for Swift to be great over the long term than to have any individual little feature “now”.</div><span class="m_7167906379274664237gmail-m_1969664532381640586HOEnZb"><font color="#888888"><div><br></div><div>-Chris</div><div><br></div></font></span></div><br></div></blockquote></div><br></div></div></div></div></div>