[swift-evolution] Swift 3 vs "additive" proposals

Erica Sadun erica at ericasadun.com
Wed Jun 22 09:59:12 CDT 2016

> On Jun 21, 2016, at 11:55 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
> Hi Everyone,
> 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.  

A few things on my radar.

Fully breaking that won't be possible post Swift 3:
Rationalizing the first/last/prefix/suffix/drop/etc. methods.   Brent R-G said he'd run with this. Discussion: http://article.gmane.org/gmane.comp.lang.swift.evolution/16334/ <http://article.gmane.org/gmane.comp.lang.swift.evolution/16334/>
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.
Potentially code breaking:
Rationalizing for loops-in either by removing `where` (breaking) or completing the filter/break operations (additive but wordy). Discussion here (primarily during WWDC week): http://thread.gmane.org/gmane.comp.lang.swift.evolution/20142 <http://thread.gmane.org/gmane.comp.lang.swift.evolution/20142> My draft proposal <https://github.com/erica/swift-evolution/blob/5703c94450dcf4a3bc941333d3fadd90a7bd4ad8/proposals/XXXX-whereloops.md> also addresses `where` in switch and catch statements, which could be breaking if changed to `if`.
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: http://thread.gmane.org/gmane.comp.lang.swift.evolution/20019 <http://thread.gmane.org/gmane.comp.lang.swift.evolution/20019> 
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.
-- E

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160622/bd74125b/attachment.html>

More information about the swift-evolution mailing list