<div dir="ltr">Ted Kremenek just wrote a post detailing Swift 4 stage 2. Here is the relevant part again [unable to increase the quotation level for unclear reasons, but the following is a verbatim copy from that message]:<div><h3 id="gmail-m_-6453917183690223651toc_2" style="margin:20px 0px 10px;padding:0px;font-size:18px;font-family:helvetica,arial,sans-serif">Timeline</h3><p style="margin:15px 0px;font-family:helvetica,arial,sans-serif;font-size:14px">Stage 2 starts right now. All design work and discussion for stage 2 extends to <strong><span class="gmail-aBn" tabindex="0"><span class="gmail-aQJ">April 1, 2017</span></span></strong>. The intent is to timebox discussion to provide adequate time for the actual implementation of accepted proposals.</p><h3 id="gmail-m_-6453917183690223651toc_3" style="margin:20px 0px 10px;padding:0px;font-size:18px;font-family:helvetica,arial,sans-serif">Scope</h3><p style="margin:15px 0px;font-family:helvetica,arial,sans-serif;font-size:14px">Swift 4 stage 2 builds on the goals of stage 1. It differs in that stage 2 proposals may include some additive changes and changes to existing features that don't affect the ABI. There are a few focus areas for Swift 4 stage 2:</p><ul style="margin:15px 0px;padding-left:30px;font-family:helvetica,arial,sans-serif;font-size:14px"><li style="margin:0px"><p style="margin:0px 0px 15px"><strong style="margin-top:0px">Stage 1 proposals</strong>: Any proposal that would have been eligible for stage 1 is a priority for stage 2.</p></li><li style="margin:0px"><p style="margin:0px 0px 15px"><strong style="margin-top:0px">Source-breaking changes</strong>: The Swift 4 compiler will provide a source-compatibility mode to allow existing Swift 3 sources to compile, but source-breaking changes can manifest in "Swift 4" mode. That said, changes to fundamental parts of Swift's syntax or standard library APIs that breaks source code are better front-loaded into Swift 4 than delayed until later releases. Relative to Swift 3, the bar for such changes is significantly higher:</p><ul style="margin:15px 0px;padding-left:30px"><li style="margin:0px">The existing syntax/API being changed must be <em style="margin-top:0px">actively harmful</em>.</li><li style="margin:0px">The new syntax/API must <em style="margin-top:0px">clearly</em> be better and not conflict with existing Swift syntax.</li><li style="margin:0px">There must be a <em style="margin-top:0px">reasonably automatable migration path</em> for existing code.</li></ul></li><li style="margin:0px"><p style="margin:0px 0px 15px"><strong style="margin-top:0px">Improvements to existing Standard Library facilities</strong>: Additive changes that improve existing standard library facilities can be considered. With standard library additions in particular, proposals that provide corresponding implementations are preferred. Potential focus areas for improvement include collections (e.g., new collection algorithms) and improvements to the ergonomics of <code style="margin:0px 2px;padding:0px 5px;white-space:nowrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px">Dictionary</code>.</p></li><li style="margin:0px"><p style="margin:0px 0px 15px"><strong style="margin-top:0px">Foundation improvements</strong>: We anticipate proposing some targeted improvements to Foundation API to continue the goal of making the Cocoa SDK work seamlessly in Swift. Details on the specific goals will be provided as we get started on Swift 4 stage 2.</p></li></ul></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Feb 18, 2017 at 11:59 PM, Kevin Nattinger via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></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"><div dir="auto" style="word-wrap:break-word"><br><div><span class=""><blockquote type="cite"><div>On Feb 18, 2017, at 7:33 PM, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_-5489292640980542370Apple-interchange-newline"><div><div style="word-wrap:break-word"><br><div><blockquote type="cite"><div>On Feb 17, 2017, at 12:20 AM, Adrian Zubarev via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_-5489292640980542370Apple-interchange-newline"><div><div class="m_-5489292640980542370bloop_markdown" style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254)"><p style="margin:15px 0px">I’d like to revive an additive proposal that couldn’t make it into Swift 3. This proposal has a small improvement to the language compared to other big features currently being proposed. It almost feels like a bug fix rather than a new feature, but it still needs a full and quick review process.</p><p style="margin:15px 0px">You can read the formatted version here:<span class="m_-5489292640980542370Apple-converted-space"> </span><a href="https://github.com/apple/swift-evolution/pull/608" style="color:rgb(65,131,196);background-color:inherit;text-decoration:none" target="_blank">https://github.com/<wbr>apple/swift-evolution/pull/608</a></p></div></div></blockquote></div><div>Just MHO, but I consider this syntactic sugar, not a fundamental feature that fits the goal of Swift 4 stage 2. </div></div></div></blockquote><div><br></div></span>Not that I’m necessarily in favor of this change, but my impression was that the whole point of stage 1/2 was that anything not allowed in stage 1 is fair game in stage 2 (if it happens; that doesn’t seem to be likely at this point). What exactly is the goal of stage 2 then, should there actually be time for it?</div><div><br><blockquote type="cite"><div><span class=""><div style="word-wrap:break-word"><div><br></div><div>I’m also pretty opposed to doing it at any time. The rationale of “implicit return” in closures is specifically because they are limited to a single expression, which makes the semantics “obvious”. This was carefully considered.</div><div><br></div><div>-Chris</div><br></div></span><span class="">______________________________<wbr>_________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br></span></div></blockquote></div><br></div></div><br>______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
<br></blockquote></div><br></div></div>