<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=""><div><blockquote type="cite" class=""><div class="">On Jun 22, 2016, at 9:59 AM, Erica Sadun via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jun 21, 2016, at 11:55 PM, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Hi Everyone,<br class=""><br class="">As I mentioned before, the Swift 3 release is winding down. There is still time left to make changes, but it is very short. As such, we - as a community - need to stay focused on the goals for this release, principally the goal to get to source stability. It is very important for users of Swift that Swift 3 and the Swift 4 compiler be as compatible as possible. </div></div></blockquote><br class=""></div><div class="">A few things on my radar.</div><div class=""><br class=""></div><div class="">Fully breaking that won't be possible post Swift 3:</div><div class=""><ul class=""><li class="">Rationalizing the<span style="font-family: Palatino-Roman;" class=""> first/last/prefix/suffix/drop/etc. methods. </span> Brent R-G said he'd run with this. Discussion: <a href="http://article.gmane.org/gmane.comp.lang.swift.evolution/16334/" class="">http://article.gmane.org/gmane.comp.lang.swift.evolution/16334/</a></li><li class="">Rationalizing base conversion protocol names. I personally don't have the heart to try to re-address the "LiteralConvertible" protocol naming thing again but this would be the last chance to do anything about getting this issue addressed.</li></ul><div class=""><div class="">Potentially code breaking:</div></div><ul class=""><li class="">Rationalizing for loops-in either by removing `where` (breaking) or completing the filter/break operations (additive but wordy). Discussion here (primarily during WWDC week): <a href="http://thread.gmane.org/gmane.comp.lang.swift.evolution/20142" class="">http://thread.gmane.org/gmane.comp.lang.swift.evolution/20142</a> My <a href="https://github.com/erica/swift-evolution/blob/5703c94450dcf4a3bc941333d3fadd90a7bd4ad8/proposals/XXXX-whereloops.md" class="">draft proposal</a> also addresses `where` in switch and catch statements, which could be breaking if changed to `if`.</li><li class="">Redesigning de-init to allow you to declare cleanup operations at points where the dangerous operations are first invoked. Introduced by Graham Perks but ran into WWDC disruption of discussion. Discussion here: <a href="http://thread.gmane.org/gmane.comp.lang.swift.evolution/20019" class="">http://thread.gmane.org/gmane.comp.lang.swift.evolution/20019</a> </li><li class="">Ending the strong-weak dance once and for all by allowing {self in} and [weak self] / guard let self = self, which would impact a lot of code more than be breaking in and of itself.</li></ul></div></div></div></blockquote><div>That's a great list, Erica—I'd also add:</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>- Closure parameter / argument label revisions from Dave Abrahams (upcoming)</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>- Functional algorithm renaming from Patrick Pijnappel (upcoming)</div><div><br class=""></div><div>I did a quick look through the proposals listed in schedule.md and the yet-to-be-merged proposals to see what might be source breaking. Without passing judgement on whether these should be scheduled, included, or accepted, this is what I came up with:</div><div><br class=""></div><div><div><b class="">Merged Proposals</b></div><div><br class=""></div><div>The merged proposals that are / have been in review are by some coincidence all source breaking. The two remaining unscheduled proposals are additive.</div><div><br class=""></div><div><i class="">Breaking</i></div></div></div>SE-0086: Drop NS Prefix in Swift Foundation<br class="">SE-0103: Make non-escaping closures the default<br class="">SE-0077: Improved operator declarations<br class="">SE-0091: Improving operator requirements in protocols<br class="">SE-0089: Renaming String.init<T>(_: T)<br class="">SE-0101: Rename sizeof and related functions to comply with API Guidelines<br class="">SE-0102: Remove @noreturn attribute and introduce an empty NoReturn type<br class=""><div><div><div>SE-0103: Make non-escaping closures the default</div></div></div><div><div><div><br class=""></div><div><i class="">Additive</i></div></div></div>SE-0079: Allow using optional binding to upgrade self from a weak to strong reference<br class=""><div><div><div>SE-0100: Add sequence-based initializers and merge methods to Dictionary</div></div></div><div><div><div><br class=""></div><div><b class="">Pull Requests</b></div><div><br class=""></div><div>Of the proposals waiting to be merged, I counted six source-breaking changes plus another that would almost certainly have breaking follow-on effects in the standard library.</div><div><br class=""></div><div><i class="">Breaking</i></div><div>#374 [WIP] Protocol oriented integers: Lots of big changes to the numerics system</div><div>#218 Throwing Properties and Subscripts proposal: Includes breaking changes to the C/ObjC importer</div><div>#365 Shorthand Argument Renaming: Would require changing $0, $1,... to #0, #1,...</div><div>#362 Removing Where Clauses from For-In Loops: Requires refactoring for-in loops that include where clauses</div><div>#354 Proposal: Allow Single Dollar Sign as Valid Identified: This would codify existing behavior that has been filed as a bug</div><div>#329 Proposal: Add last(where:) and lastIndex(where:) Methods to Collections: Renames existing index(of:) and index(where:) collection methods</div><div><br class=""></div><div><i class="">In-between</i></div><div>#284 More Powerful Constraints for Associated Types: Additive, but has major ramifications for the stdlib that could be source-breaking</div><div> </div><div><i class="">Additive</i></div><div>#372 [Proposal] Generic and Throwing Subscripts</div><div>#371 Enum case stored properties proposal<span class="Apple-tab-span" style="white-space:pre"> </span></div><div>#369 Conditional Compilation Blocks proposal <span class="Apple-tab-span" style="white-space:pre"> </span></div><div>#367 Create NNNN-directional-index-methods.md</div><div>#366 Create NNNN-unboxing-anyindex.md</div><div>#353 #warning</div><div>#346 Introducing with to the Standard Library<span class="Apple-tab-span" style="white-space:pre"> </span></div><div>#328 Proposal: more lenient subscript methods over Collections<span class="Apple-tab-span" style="white-space:pre"> </span></div><div>#322 Multi-line string literal proposals</div><div>#247 Proposal: Factory Initializers</div><div>#211 Create 0052-enforcing_calling_super.md</div><div>#114 Deriving collections of enum cases</div><div>#103 Tail Call Optimization attribute and modifier</div><div>#140 Implementing `Comparable` On `NSOperatingSystemVersion`</div><div><br class=""></div><div><i class="">Other</i></div><div>#370 Renaming the OS X Platform Conditional Compilation Test: Doug Gregor suggested this could just be implemented as a bug fix</div></div></div><br class=""><div class="">-Nate</div><div class=""><br class=""></div></body></html>