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

Nate Cook natecook at gmail.com
Wed Jun 22 11:05:36 CDT 2016


> On Jun 22, 2016, at 9:59 AM, Erica Sadun via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> On Jun 21, 2016, at 11:55 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org <mailto: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.
That's a great list, Erica—I'd also add:
	- Closure parameter / argument label revisions from Dave Abrahams (upcoming)
	- Functional algorithm renaming from Patrick Pijnappel (upcoming)

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:

Merged Proposals

The merged proposals that are / have been in review are by some coincidence all source breaking. The two remaining unscheduled proposals are additive.

Breaking
SE-0086: Drop NS Prefix in Swift Foundation
SE-0103: Make non-escaping closures the default
SE-0077: Improved operator declarations
SE-0091: Improving operator requirements in protocols
SE-0089: Renaming String.init<T>(_: T)
SE-0101: Rename sizeof and related functions to comply with API Guidelines
SE-0102: Remove @noreturn attribute and introduce an empty NoReturn type
SE-0103: Make non-escaping closures the default

Additive
SE-0079: Allow using optional binding to upgrade self from a weak to strong reference
SE-0100: Add sequence-based initializers and merge methods to Dictionary

Pull Requests

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.

Breaking
#374 [WIP] Protocol oriented integers: Lots of big changes to the numerics system
#218 Throwing Properties and Subscripts proposal: Includes breaking changes to the C/ObjC importer
#365 Shorthand Argument Renaming: Would require changing $0, $1,... to #0, #1,...
#362 Removing Where Clauses from For-In Loops: Requires refactoring for-in loops that include where clauses
#354 Proposal: Allow Single Dollar Sign as Valid Identified: This would codify existing behavior that has been filed as a bug
#329 Proposal: Add last(where:) and lastIndex(where:) Methods to Collections: Renames existing index(of:) and index(where:) collection methods

In-between
#284 More Powerful Constraints for Associated Types: Additive, but has major ramifications for the stdlib that could be source-breaking
    
Additive
#372 [Proposal] Generic and Throwing Subscripts
#371 Enum case stored properties proposal	
#369 Conditional Compilation Blocks proposal 		
#367 Create NNNN-directional-index-methods.md
#366 Create NNNN-unboxing-anyindex.md
#353 #warning
#346 Introducing with to the Standard Library		
#328 Proposal: more lenient subscript methods over Collections	
#322 Multi-line string literal proposals
#247 Proposal: Factory Initializers
#211 Create 0052-enforcing_calling_super.md
#114 Deriving collections of enum cases
#103 Tail Call Optimization attribute and modifier
#140 Implementing `Comparable` On `NSOperatingSystemVersion`

Other
#370 Renaming the OS X Platform Conditional Compilation Test: Doug Gregor suggested this could just be implemented as a bug fix

-Nate

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


More information about the swift-evolution mailing list