The Swift evolution process describes the process by which Swift evolves. This page tracks the currently active proposals in that process.
- -(none)
--func documentForURL(_: NSURL) -> NSDocument? -+ func documentForURL(_: NSURL) -> NSDocument? + - while preventing partial-word mismatches: + while preventing partial-word mismatches: -
- var thumbnailPreview : UIView // not matched -+
+ var thumbnailPreview : UIView // not matched +* **Matched text extends to the end of the type name**. Because we accept a match for *any suffix* of the type name, this code: @@ -313,14 +313,14 @@ Matches are a sequence of one or more of the following: matches `String` in `NSString`:
-func appendString(_: NSString) -+ func appendString(_: NSString) + * `Index` in the selector piece matches `Int` in the type name:
-func characterAtIndex(_: Int) -> unichar -+ func characterAtIndex(_: Int) -> unichar + * **Collection matches** @@ -328,33 +328,33 @@ func characterAtIndex(_: Int) -> unichar the type name:
-func removeObjectsAtIndexes(_: NSIndexSet) -+ func removeObjectsAtIndexes(_: NSIndexSet) + * A plural noun in the selector piece matches a collection type name if the noun's singular form matches the name of the collection's element type: -
-func arrangeObjects(_: [AnyObject]) -> [AnyObject] -+
+ func arrangeObjects(_: [AnyObject]) -> [AnyObject] +* **Special suffix matches** * The empty string in the selector piece matches `Type` or `_t` in the type name:
-func writableTypesForSaveOperation(_: NSSaveOperationType) -> [String] -func objectForKey(_: KeyType) -> AnyObject -func startWithQueue(_: dispatch_queue_t, completionHandler: MKMapSnapshotCompletionhandler) -+ func writableTypesForSaveOperation(_: NSSaveOperationType) -> [String] + func objectForKey(_: KeyType) -> AnyObject + func startWithQueue(_: dispatch_queue_t, completionHandler: MKMapSnapshotCompletionhandler) + * The empty string in the selector piece matches *one or more digits followed by "D"* in the type name:
-func pointForCoordinate(_: CLLocationCoordinate2D) -> NSPoint -+ func pointForCoordinate(_: CLLocationCoordinate2D) -> NSPoint + In the examples above, the italic text is effectively skipped, so the bold part of the selector piece can be matched and pruned. @@ -378,27 +378,27 @@ skipped. user to write backticks. For example,
-extension NSParagraphStyle {
- class func defaultParagraphStyle() -> NSParagraphStyle
-}
-let defaultStyle = NSParagraphStyle.defaultParagraphStyle() // OK
-
+ extension NSParagraphStyle {
+ class func defaultParagraphStyle() -> NSParagraphStyle
+ }
+ let defaultStyle = NSParagraphStyle.defaultParagraphStyle() // OK
+
would become:
-extension NSParagraphStyle {
- class func `default`() -> NSParagraphStyle
-}
-let defaultStyle = NSParagraphStyle.`default`() // Awkward
-
+ extension NSParagraphStyle {
+ class func `default`() -> NSParagraphStyle
+ }
+ let defaultStyle = NSParagraphStyle.`default`() // Awkward
+
By contrast, later selector pieces become argument labels, which
are allowed to match Swift keywords without requiring backticks:
-receiver.handle(someMessage, for: somebody) // OK -+ receiver.handle(someMessage, for: somebody) // OK + * **Never transform a name into "get", "set", "with", "for", or "using"**, just to avoid creating absurdly vacuous names. @@ -413,19 +413,19 @@ receiver.handle(someMessage, for: somebody) // OK the parameter that follows. For example,
-func setTextColor(_: UIColor) -... -button.setTextColor(.red()) // clear -+ func setTextColor(_: UIColor) + ... + button.setTextColor(.red()) // clear + If we were to drop `Color`, leaving just `Text`, call sites would become confusing:
-func setText(_: UIColor) -... -button.setText(.red()) // appears to be setting the text! -+ func setText(_: UIColor) + ... + button.setText(.red()) // appears to be setting the text! + Note: We don't maintain a list of nouns, but if we did, this rule could be more simply phrased as "don't prune a suffix @@ -438,9 +438,9 @@ button.setText(.red()) // appears to be setting the text! of the class.
-var gestureRecognizers: [UIGestureRecognizer] -func addGestureRecognizer(_: UIGestureRecognizer) -+ var gestureRecognizers: [UIGestureRecognizer] + func addGestureRecognizer(_: UIGestureRecognizer) + If we were to drop `GestureRecognizer`, leaving just `add`, we end up with a method that conceptually modifies the @@ -448,9 +448,9 @@ func addGestureRecognizer(_: UIGestureRecognizer) do so:
-var gestureRecognizers: [UIGestureRecognizer] -func add(_: UIGestureRecognizer) // should indicate that we're adding to the property -+ var gestureRecognizers: [UIGestureRecognizer] + func add(_: UIGestureRecognizer) // should indicate that we're adding to the property + #### Pruning Steps @@ -471,20 +471,20 @@ shown: receiver. For example:
-extension NSColor {
- func colorWithAlphaComponent(_: CGFloat) -> NSColor
-}
-let translucentForeground = foregroundColor.colorWithAlphaComponent(0.5)
-
+ extension NSColor {
+ func colorWithAlphaComponent(_: CGFloat) -> NSColor
+ }
+ let translucentForeground = foregroundColor.colorWithAlphaComponent(0.5)
+
becomes:
-extension NSColor {
- func withAlphaComponent(_: CGFloat) -> NSColor
-}
-let translucentForeground = foregroundColor.withAlphaComponent(0.5)
-
+ extension NSColor {
+ func withAlphaComponent(_: CGFloat) -> NSColor
+ }
+ let translucentForeground = foregroundColor.withAlphaComponent(0.5)
+
2. **Prune an additional hanging "By"**. Specifically, if
@@ -497,20 +497,20 @@ let translucentForeground = foregroundColor.withAlphaComponent(0.5
b.frobnicating(c)`. For example:
-extension NSString {
- func stringByApplyingTransform(_: NSString, reverse: Bool) -> NSString?
-}
-let sanitizedInput = rawInput.stringByApplyingTransform(NSStringTransformToXMLHex, reverse: false)
-
+ extension NSString {
+ func stringByApplyingTransform(_: NSString, reverse: Bool) -> NSString?
+ }
+ let sanitizedInput = rawInput.stringByApplyingTransform(NSStringTransformToXMLHex, reverse: false)
+
becomes:
-extension NSString {
- func applyingTransform(_: NSString, reverse: Bool) -> NString?
-}
-let sanitizedInput = rawInput.applyingTransform(NSStringTransformToXMLHex, reverse: false)
-
+ extension NSString {
+ func applyingTransform(_: NSString, reverse: Bool) -> NString?
+ }
+ let sanitizedInput = rawInput.applyingTransform(NSStringTransformToXMLHex, reverse: false)
+
3. **Prune a match for any type name in the signature from the tail of
the preceding selector piece**. Specifically,
@@ -524,54 +524,54 @@ let sanitizedInput = rawInput.applyingTransform(NSStringTransformToXMLHex
For example,
-extension NSDocumentController {
- func documentForURL(_ url: NSURL) -> NSDocument? // parameter introducer
-}
-extension NSManagedObjectContext {
- var parentContext: NSManagedObjectContext? // property
-}
-extension UIColor {
- class func darkGrayColor() -> UIColor // zero-argument method
-}
-...
-myDocument = self.documentForURL(locationOfFile)
-if self.managedObjectContext.parentContext != changedContext { return }
-foregroundColor = .darkGrayColor()
-
+ extension NSDocumentController {
+ func documentForURL(_ url: NSURL) -> NSDocument? // parameter introducer
+ }
+ extension NSManagedObjectContext {
+ var parentContext: NSManagedObjectContext? // property
+ }
+ extension UIColor {
+ class func darkGrayColor() -> UIColor // zero-argument method
+ }
+ ...
+ myDocument = self.documentForURL(locationOfFile)
+ if self.managedObjectContext.parentContext != changedContext { return }
+ foregroundColor = .darkGrayColor()
+
becomes:
-extension NSDocumentController {
- func documentFor(_ url: NSURL) -> NSDocument?
-}
-extension NSManagedObjectContext {
- var parent : NSManagedObjectContext?
-}
-extension UIColor {
- class func darkGray() -> UIColor
-}
-...
-myDocument = self.documentFor(locationOfFile)
-if self.managedObjectContext.parent != changedContext { return }
-foregroundColor = .darkGray()
-
+ extension NSDocumentController {
+ func documentFor(_ url: NSURL) -> NSDocument?
+ }
+ extension NSManagedObjectContext {
+ var parent : NSManagedObjectContext?
+ }
+ extension UIColor {
+ class func darkGray() -> UIColor
+ }
+ ...
+ myDocument = self.documentFor(locationOfFile)
+ if self.managedObjectContext.parent != changedContext { return }
+ foregroundColor = .darkGray()
+
3. **Prune a match for the enclosing type from the base name of a method so long as the match starts after a verb**. For example,
-extension UIViewController {
- func dismissViewControllerAnimated(flag: Bool, completion: (() -> Void)? = nil)
-}
-
+ extension UIViewController {
+ func dismissViewControllerAnimated(flag: Bool, completion: (() -> Void)? = nil)
+ }
+
becomes:
-extension UIViewController {
- func dismissAnimated(flag: Bool, completion: (() -> Void)? = nil)
-}
-
+ extension UIViewController {
+ func dismissAnimated(flag: Bool, completion: (() -> Void)? = nil)
+ }
+
##### Why Does Order Matter?
@@ -581,10 +581,12 @@ prevent both the head and tail from being pruned, prioritizing
head-pruning steps can keep method families together. For example,
in NSFontDescriptor:
- func fontDescriptorWithSymbolicTraits(_: NSFontSymbolicTraits) -> NSFontDescriptor
- func fontDescriptorWithSize(_: CGFloat) -> UIFontDescriptor
- func fontDescriptorWithMatrix(_: CGAffineTransform) -> UIFontDescriptor
- ...
+```swift
+func fontDescriptorWithSymbolicTraits(_: NSFontSymbolicTraits) -> NSFontDescriptor
+func fontDescriptorWithSize(_: CGFloat) -> UIFontDescriptor
+func fontDescriptorWithMatrix(_: CGAffineTransform) -> UIFontDescriptor
+...
+```
becomes:
@@ -633,9 +635,11 @@ UIView.animateWithDuration(
to become:
- rootViewController.present(alert, animated: true)
- UIView.animateWithDuration(
- 0.2, delay: 0.0, animations: { self.logo.alpha = 0.0 }) { _ in self.logo.hidden = true }
+```swift
+rootViewController.present(alert, animated: true)
+UIView.animateWithDuration(
+ 0.2, delay: 0.0, animations: { self.logo.alpha = 0.0 }) { _ in self.logo.hidden = true }
+```
#### Add First Argument Labels
@@ -684,8 +688,10 @@ array.enumerateObjects() { // OK
**For Boolean properties, use the name of the getter as the property
name in Swift*. For example:
- @interface NSBezierPath : NSObject
- @property (readonly,getter=isEmpty) BOOL empty;
+```swift
+@interface NSBezierPath : NSObject
+@property (readonly,getter=isEmpty) BOOL empty;
+```
will become
@@ -712,13 +718,13 @@ as adopting `Comparable`.
A survey of Foundation classes reveals not just NSDate but a few
other classes that would be affected by this change.
-+```swift func compare(other: NSDate) -> NSComparisonResult func compare(decimalNumber: NSNumber) -> NSComparisonResult func compare(otherObject: NSIndexPath) -> NSComparisonResult func compare(string: String) -> NSComparisonResult func compare(otherNumber: NSNumber) -> NSComparisonResult -+``` ## Impact on existing code diff --git a/proposals/0006-apply-api-guidelines-to-the-standard-library.md b/proposals/0006-apply-api-guidelines-to-the-standard-library.md index d36883ac4e..76349a2287 100644 --- a/proposals/0006-apply-api-guidelines-to-the-standard-library.md +++ b/proposals/0006-apply-api-guidelines-to-the-standard-library.md @@ -3,8 +3,8 @@ * Proposal: [SE-0006](0006-apply-api-guidelines-to-the-standard-library.md) * Authors: [Dave Abrahams](https://github.com/dabrahams), [Dmitri Gribenko](https://github.com/gribozavr), [Maxim Moiseev](https://github.com/moiseev) * Review Manager: [Doug Gregor](https://github.com/DougGregor) -* Status: **Implemented (Swift 3)** -* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution-announce/2016-March/000054.html) +* Status: **Implemented (Swift 3.0)** +* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-with-modifications-se-0006-apply-api-guidelines-to-the-standard-library/1667) ## Reviewer notes @@ -12,11 +12,11 @@ This review is part of a group of three related reviews, running concurrently: * [SE-0023 API Design Guidelines](0023-api-guidelines.md) - ([Review](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160118/007353.html)) + ([Review](https://forums.swift.org/t/review-se-0023-api-design-guidelines/1162)) * [SE-0006 Apply API Guidelines to the Standard Library](0006-apply-api-guidelines-to-the-standard-library.md) - ([Review](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160118/007354.html)) + ([Review](https://forums.swift.org/t/review-se-0006-apply-api-guidelines-to-the-standard-library/1163)) * [SE-0005 Better Translation of Objective-C APIs Into Swift](0005-objective-c-name-translation.md) - ([Review](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160118/007355.html)) + ([Review](https://forums.swift.org/t/review-se-0005-better-translation-of-objective-c-apis-into-swift/1164)) These reviews are running concurrently because they interact strongly (e.g., an API change in the standard library will correspond to a @@ -1144,7 +1144,7 @@ public struct OpaquePointer : ... { - allowedCharacters: NSCharacterSet - ) -> String? + public func addingPercentEncoding( -+ withAllowedCharaters allowedCharacters: NSCharacterSet ++ withAllowedCharacters allowedCharacters: NSCharacterSet + ) -> String? - public func stringByAddingPercentEscapesUsingEncoding( diff --git a/proposals/0007-remove-c-style-for-loops.md b/proposals/0007-remove-c-style-for-loops.md index def47e117c..1bef3ab55a 100644 --- a/proposals/0007-remove-c-style-for-loops.md +++ b/proposals/0007-remove-c-style-for-loops.md @@ -3,8 +3,8 @@ * Proposal: [SE-0007](0007-remove-c-style-for-loops.md) * Author: [Erica Sadun](https://github.com/erica) * Review Manager: [Doug Gregor](https://github.com/DougGregor) -* Status: **Implemented (Swift 3)** -* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution-announce/2015-December/000001.html) +* Status: **Implemented (Swift 3.0)** +* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-se-0007-remove-c-style-for-loops-with-conditions-and-incrementers/512) * Bugs: [SR-226](https://bugs.swift.org/browse/SR-226), [SR-227](https://bugs.swift.org/browse/SR-227) ## Introduction @@ -19,7 +19,7 @@ language. The value of this construct is limited and I believe its removal should be seriously considered. -This proposal was discussed on the Swift Evolution list in the [C-style For Loops](https://lists.swift.org/pipermail/swift-evolution/2015-December/000053.html) thread and reviewed in the [\[Review\] Remove C-style for-loops with conditions and incrementers](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/000913.html) thread. +This proposal was discussed on the Swift Evolution list in the [C-style For Loops](https://forums.swift.org/t/c-style-for-loops/31) thread and reviewed in the [\[Review\] Remove C-style for-loops with conditions and incrementers](https://forums.swift.org/t/review-remove-c-style-for-loops-with-conditions-and-incrementers/255) thread. ## Advantages of For Loops @@ -101,6 +101,6 @@ for(var i=0 ; i < array.count ;i++){ * "For what it's worth we don't have a single C style for loop in the Lyft codebase." -- Keith Smiley, keithbsmiley@gmail.com * "Just checked; ditto Khan Academy." -- Andy Matsuchak, andy@andymatuschak.org * "We’ve developed a number of Swift apps for various clients over the past year and have not needed C style for loops either." -- Eric Chamberlain, eric.chamberlain@arctouch.com -* "Every time I've tried to use a C-style for loop, I've ended up switching to a while loop because my iteration variable ended up having the wrong type (e.g. having an optional type when the value must be non-optional for the body to execute). The Postmates codebase contains no instances of C-style for loops in Swift." -- Kevin Ballard, kevin@sb.org +* "Every time I've tried to use a C-style for loop, I've ended up switching to a while loop because my iteration variable ended up having the wrong type (e.g. having an optional type when the value must be non-optional for the body to execute). The Postmates codebase contains no instances of C-style for loops in Swift." -- Lily Ballard, lily@sb.org * "I found a couple of cases of them in my codebase, but they were trivially transformed into “proper” Swift-style for loops that look better anyway. If it were a vote, I’d vote for eliminating C-style." -- Sean Heber, sean@fifthace.com diff --git a/proposals/0008-lazy-flatmap-for-optionals.md b/proposals/0008-lazy-flatmap-for-optionals.md index 8ec4f70956..2abda3ceee 100644 --- a/proposals/0008-lazy-flatmap-for-optionals.md +++ b/proposals/0008-lazy-flatmap-for-optionals.md @@ -3,8 +3,8 @@ * Proposal: [SE-0008](0008-lazy-flatmap-for-optionals.md) * Author: [Oisin Kidney](https://github.com/oisdk) * Review Manager: [Doug Gregor](https://github.com/DougGregor) -* Status: **Implemented (Swift 3)** -* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151221/004418.html) +* Status: **Implemented (Swift 3.0)** +* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-se-0008-add-a-lazy-flatmap-for-sequences-of-optionals/748) * Bug: [SR-361](https://bugs.swift.org/browse/SR-361) ## Introduction ## @@ -39,7 +39,7 @@ However, there is only a lazy implementation for the first version: // [1, 2, 3, 4, 5] ``` -Swift Evolution Discussions: [Lazy flatMap for Optionals](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151130/000534.html), [Review](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/002592.html) +Swift Evolution Discussions: [Lazy flatMap for Optionals](https://forums.swift.org/t/lazy-flatmap-for-optionals/127/3), [Review](https://forums.swift.org/t/review-add-a-lazy-flatmap-for-sequences-of-optionals/548) ## Motivation ## diff --git a/proposals/0009-require-self-for-accessing-instance-members.md b/proposals/0009-require-self-for-accessing-instance-members.md index 737a62e7ff..626f78665e 100644 --- a/proposals/0009-require-self-for-accessing-instance-members.md +++ b/proposals/0009-require-self-for-accessing-instance-members.md @@ -4,13 +4,13 @@ * Author: [David Hart](https://github.com/hartbit) * Review Manager: [Doug Gregor](https://github.com/DougGregor) * Status: **Rejected** -* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160104/005478.html) +* Decision Notes: [Rationale](https://forums.swift.org/t/rejected-se-0009-require-self-for-accessing-instance-members/930) ## Introduction The current version of Swift (2.1) requires using `self` when accessing instance members in closures. The proposal suggests extending this to all member accesses (as is intrinsically the case in Objective-C). It has the benefit of documenting instance properties vs local variables and instance functions vs local functions or closures. -[Swift Evolution Discussion Thread](https://lists.swift.org/pipermail/swift-evolution/2015-December/000209.html) +[Swift Evolution Discussion Thread](https://forums.swift.org/t/proposal-re-instate-mandatory-self-for-accessing-instance-properties-and-functions/125) ## Motivation @@ -21,7 +21,7 @@ This proposal makes it obvious which are instance properties vs local variables, * Less confusing from a learning point of view. * Lets the compiler warn users (and avoids bugs) where the authors mean to use a local variable but instead are unknowingly using an instance property (and the other way round). -One example of a bug avoidable by the proposal ([provided by Rudolf Adamkovic](https://lists.swift.org/pipermail/swift-evolution/2015-December/000243.html)): +One example of a bug avoidable by the proposal ([provided by Rudolf Adamkovic](https://forums.swift.org/t/proposal-re-instate-mandatory-self-for-accessing-instance-properties-and-functions/125/4)): ```swift class MyViewController : UIViewController { diff --git a/proposals/0010-add-staticstring-unicodescalarview.md b/proposals/0010-add-staticstring-unicodescalarview.md index dc4d4c1a5e..ac3a792444 100644 --- a/proposals/0010-add-staticstring-unicodescalarview.md +++ b/proposals/0010-add-staticstring-unicodescalarview.md @@ -1,17 +1,17 @@ # Add StaticString.UnicodeScalarView * Proposal: [SE-0010](0010-add-staticstring-unicodescalarview.md) -* Author: [Kevin Ballard](https://github.com/kballard) +* Author: [Lily Ballard](https://github.com/lilyball) * Review Manager: [Doug Gregor](https://github.com/DougGregor) * Status: **Rejected** -* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution-announce/2016-February/000045.html) +* Decision Notes: [Rationale](https://forums.swift.org/t/rejected-se-0010-add-staticstring-unicodescalarview/1530) ## Introduction There is no way to create a substring of a `StaticString` that is still typed as `StaticString`. There should be. -[Swift Evolution Discussion Thread](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151130/000535.html), [Review](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160104/005609.html) +[Swift Evolution Discussion Thread](https://forums.swift.org/t/proposal-add-staticstring-unicodescalarview/199), [Review](https://forums.swift.org/t/review-se-0010-add-staticstring-unicodescalarview/942) ## Motivation diff --git a/proposals/0011-replace-typealias-associated.md b/proposals/0011-replace-typealias-associated.md index dc17e45ba9..89d7a3d25e 100644 --- a/proposals/0011-replace-typealias-associated.md +++ b/proposals/0011-replace-typealias-associated.md @@ -4,7 +4,7 @@ * Author: [Loïc Lecrenier](https://github.com/loiclec) * Review Manager: [Doug Gregor](https://github.com/DougGregor) * Status: **Implemented (Swift 2.2)** -* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution-announce/2016-January/000014.html) +* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-se-0011-replace-typealias-keyword-with-associatedtype-for-associated-type-declarations/990) * Bug: [SR-511](https://bugs.swift.org/browse/SR-511) @@ -21,7 +21,7 @@ confusion surrounding the use of associated types. The proposed new keyword is `associatedtype`. -[Review Thread](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151228/005123.html) +[Review Thread](https://forums.swift.org/t/review-replace-typealias-keyword-with-associatedtype-for-associated-type-declarations/880) ## Motivation @@ -105,5 +105,5 @@ could be easily automated without any risk of breaking existing code. ## Mailing List -- [Original](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151130/000470.html) -- [Alternative Keywords](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003551.html) +- [Original](https://forums.swift.org/t/introduce-associated-type-keyword/201) +- [Alternative Keywords](https://forums.swift.org/t/se-0011-re-considering-the-replacement-keyword-for-typealias/669) diff --git a/proposals/0012-add-noescape-to-public-library-api.md b/proposals/0012-add-noescape-to-public-library-api.md index 9678927780..9e9c0d95e6 100644 --- a/proposals/0012-add-noescape-to-public-library-api.md +++ b/proposals/0012-add-noescape-to-public-library-api.md @@ -4,7 +4,7 @@ * Author: [Jacob Bandes-Storch](https://github.com/jtbandes) * Review Manager: [Philippe Hausler](https://github.com/phausler) * Status: **Rejected** -* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160530/019902.html) +* Decision Notes: [Rationale](https://forums.swift.org/t/rejected-se-0097-normalizing-naming-for-negative-attributes/2854/9) ##### Revision history @@ -18,7 +18,7 @@ * We propose exposing this attribute in CF and Foundation as `CF_NOESCAPE` and `NS_NOESCAPE` * We also propose applying this declaration to a number of closure-taking APIs in CF and Foundation -[Swift Evolution Discussion Thread](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160201/009270.html) +[Swift Evolution Discussion Thread: \[Pitch\] make @noescape the default](https://forums.swift.org/t/pitch-make-noescape-the-default/664) ## Introduction diff --git a/proposals/0013-remove-partial-application-super.md b/proposals/0013-remove-partial-application-super.md index 17a9ee43af..40cfaa459c 100644 --- a/proposals/0013-remove-partial-application-super.md +++ b/proposals/0013-remove-partial-application-super.md @@ -1,10 +1,10 @@ # Remove Partial Application of Non-Final Super Methods (Swift 2.2) * Proposal: [SE-0013](0013-remove-partial-application-super.md) -* Author: [David Farler](https://github.com/bitjammer) +* Author: [Ashley Garland](https://github.com/bitjammer) * Review Manager: [Doug Gregor](https://github.com/DougGregor) * Status: **Rejected** -* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160118/007316.html) +* Decision Notes: [Rationale](https://forums.swift.org/t/rejected-se-0013-remove-partial-application-of-non-final-super-methods/1157) ## Introduction @@ -24,7 +24,7 @@ those mechanisms, I propose that we disallow partial application of non-final methods through `super`, except where the `self` parameter is implicitly captured. -[Swift Evolution Discussion Thread](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/000947.html) +[Swift Evolution Discussion Thread](https://forums.swift.org/t/swift-2-2-removing-partial-application-of-super-method-calls/264) ## Motivation diff --git a/proposals/0014-constrained-AnySequence.md b/proposals/0014-constrained-AnySequence.md index e699b371a7..48ddfbc8ed 100644 --- a/proposals/0014-constrained-AnySequence.md +++ b/proposals/0014-constrained-AnySequence.md @@ -4,7 +4,7 @@ * Author: [Max Moiseev](https://github.com/moiseev) * Review Manager: [Doug Gregor](https://github.com/DougGregor) * Status: **Implemented (Swift 2.2)** -* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution-announce/2016-January/000008.html) +* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-se-0014-constraining-anysequence-init/924) * Bug: [SR-474](https://bugs.swift.org/browse/SR-474) @@ -13,7 +13,7 @@ In order to allow `AnySequence` delegate calls to the underlying sequence, its initializer should have extra constraints. -[Swift Evolution Discussion](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/000910.html) +[Swift Evolution Discussion](https://forums.swift.org/t/restricting-anysequence-init/254) ## Motivation diff --git a/proposals/0015-tuple-comparison-operators.md b/proposals/0015-tuple-comparison-operators.md index 61a7363469..9722ed2b76 100644 --- a/proposals/0015-tuple-comparison-operators.md +++ b/proposals/0015-tuple-comparison-operators.md @@ -1,17 +1,17 @@ # Tuple comparison operators * Proposal: [SE-0015](0015-tuple-comparison-operators.md) -* Author: [Kevin Ballard](https://github.com/kballard) +* Author: [Lily Ballard](https://github.com/lilyball) * Review Manager: [Dave Abrahams](https://github.com/dabrahams) * Status: **Implemented (Swift 2.2)** -* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151221/004423.html) -* Pull Request: [apple/swift#408](https://github.com/apple/swift/pull/408) +* Decision Notes: [Rationale](https://forums.swift.org/t/review-add-a-lazy-flatmap-for-sequences-of-optionals/695/4) +* Implementation: [apple/swift#408](https://github.com/apple/swift/pull/408) ## Introduction Implement comparison operators on tuples up to some arity. -[Swift Evolution Discussion](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/000892.html), [Review](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151221/003907.html) +[Swift Evolution Discussion](https://forums.swift.org/t/proposal-implement-and-for-tuples-where-possible-up-to-some-high-arity/251), [Review](https://forums.swift.org/t/review-add-a-lazy-flatmap-for-sequences-of-optionals/695) Note: The review was initially started on the wrong thread with the wrong title and subsequently corrected. diff --git a/proposals/0016-initializers-for-converting-unsafe-pointers-to-ints.md b/proposals/0016-initializers-for-converting-unsafe-pointers-to-ints.md index 468ae1c6aa..ed282b7e13 100644 --- a/proposals/0016-initializers-for-converting-unsafe-pointers-to-ints.md +++ b/proposals/0016-initializers-for-converting-unsafe-pointers-to-ints.md @@ -3,10 +3,10 @@ * Proposal: [SE-0016](0016-initializers-for-converting-unsafe-pointers-to-ints.md) * Author: [Michael Buckley](https://github.com/MichaelBuckley) * Review Manager: [Chris Lattner](https://github.com/lattner) -* Status: **Implemented (Swift 3)** -* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution-announce/2016-March/000083.html) +* Status: **Implemented (Swift 3.0)** +* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-se-0016-adding-initializers-to-int-and-uint-to-convert-from-unsafepointer-and-unsafemutablepointer/2005) * Bug: [SR-1115](https://bugs.swift.org/browse/SR-1115) -* Previous Revision: [1](https://github.com/apple/swift-evolution/blob/ae2d7c24fff7cbdff754d9a4339e4fb02df5c690/proposals/0016-initializers-for-converting-unsafe-pointers-to-ints.md) +* Previous Revision: [1](https://github.com/swiftlang/swift-evolution/blob/ae2d7c24fff7cbdff754d9a4339e4fb02df5c690/proposals/0016-initializers-for-converting-unsafe-pointers-to-ints.md) ## Introduction @@ -16,7 +16,7 @@ allow users to call C functions with `intptr_t` and `uintptr_t` parameters, and allow users to perform more advanced pointer arithmetic than is allowed by `UnsafePointer`s. -[Swift Evolution Discussion](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001213.html), [Review](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160321/013119.html) +[Swift Evolution Discussion](https://forums.swift.org/t/proposal-add-initializers-for-converting-unsafepointers-to-int-and-unit/331), [Review](https://forums.swift.org/t/review-se-0016-adding-initializers-to-int-and-uint-to-convert-from-unsafepointer-and-unsafemutablepointer/1899) ## Motivation diff --git a/proposals/0017-convert-unmanaged-to-use-unsafepointer.md b/proposals/0017-convert-unmanaged-to-use-unsafepointer.md index 9bcade90e3..cc2bb68860 100644 --- a/proposals/0017-convert-unmanaged-to-use-unsafepointer.md +++ b/proposals/0017-convert-unmanaged-to-use-unsafepointer.md @@ -3,15 +3,15 @@ * Proposal: [SE-0017](0017-convert-unmanaged-to-use-unsafepointer.md) * Author: [Jacob Bandes-Storch](https://github.com/jtbandes) * Review Manager: [Chris Lattner](https://github.com/lattner) -* Status: **Implemented (Swift 3)** -* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution-announce/2016-May/000133.html) +* Status: **Implemented (Swift 3.0)** +* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-se-0017-change-unmanaged-to-use-unsafepointer/2461) * Bug: [SR-1485](https://bugs.swift.org/browse/SR-1485) ## Introduction The standard library [`Unmanaged
One great goal for Swift 3 is to sort out any source breaking language changes. This proposal aims to fix access modifier inconsistency on extensions compared to other scope declarations types.
+One great goal for Swift 3 is to sort out any source breaking language changes. This proposal aims to fix access modifier inconsistency on extensions compared to other scope declarations types. -Swift-evolution thread: [\[Proposal\] Revising access modifiers on extensions](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160620/022144.html) +Swift-evolution thread: [\[Proposal\] Revising access modifiers on extensions](https://forums.swift.org/t/proposal-revising-access-modifiers-on-extensions/3138) ## Motivation -The access control of classes, enums and structs in Swift is very easy to learn and memorize. It also disallows to suppress the access modifier of implemented conformance members to lower access modifier if the host type has an access modifier of higher or equal level.
+The access control of classes, enums and structs in Swift is very easy to learn and memorize. It also disallows to suppress the access modifier of implemented conformance members to lower access modifier if the host type has an access modifier of higher or equal level. -+ + ```diff + struct Version { + - func successor() -> Version + + - func predecessor() -> Version + } + ``` +
+ + Diff: + ```diff + final class Target { + - let name: String + + var name: String + } + + final class Package { + - let name: String + + var name: String + + - let pkgConfig: String? + + var pkgConfig: String? + + - let providers: [SystemPackageProvider]? + + var providers: [SystemPackageProvider]? + } + ``` + + Example: + ```swift + let package = Package( + name: "FooPackage", + targets: [ + Target(name: "Foo", dependencies: ["Bar"]), + ] + ) + + #if os(Linux) + package.targets[0].dependencies = ["BarLinux"] + #endif + ``` +
+ + Diff: + ```diff + enum Dependency { + - case Target(name: String) + + case target(name: String) + + - case Product(name: String, package: String?) + + case product(name: String, package: String?) + + - case ByName(name: String) + + case byName(name: String) + } + ``` + + Example: + ```diff + let package = Package( + name: "FooPackage", + targets: [ + Target( + name: "Foo", + dependencies: [ + - .Target(name: "Bar"), + + .target(name: "Bar"), + + - .Product(name: "SwiftyJSON", package: "SwiftyJSON"), + + .product(name: "SwiftyJSON", package: "SwiftyJSON"), + ] + ), + ] + ) + ``` +
+ + Diff: + ```diff + enum SystemPackageProvider { + - case Brew(String) + + case brew([String]) + + - case Apt(String) + + case apt([String]) + } + ``` + + Example: + + ```diff + let package = Package( + name: "Copenssl", + pkgConfig: "openssl", + providers: [ + - .Brew("openssl"), + + .brew(["openssl"]), + + - .Apt("openssl-dev"), + + .apt(["openssl", "libssl-dev"]), + ] + ) + ``` +
+ + Example: + + ```diff + let package = Package( + name: "Foo", + target: [ + - Target(name: "Foo", dependencies: ["Utility"]), + + .target(name: "Foo", dependencies: ["Utility"]), + ] + ) + ``` +
+ + Example: + + ```swift + let package = Package( + name: "Foo", + target: [ + .target(name: "Foo", dependencies: ["Utility"]), + .target(name: "tool", dependencies: ["Foo"]), + ], + products: [ + .executable(name: "tool", targets: ["tool"]), + .library(name: "Foo", targets: ["Foo"]), + .library(name: "FooDy", type: .dynamic, targets: ["Foo"]), + ] + ) + ``` +
+ + Example: + + ```swift + let package = Package( + name: "Paper", + products: [ + .executable(name: "tool", targets: ["tool"]), + .library(name: "Paper", type: .static, targets: ["Paper"]), + .library(name: "PaperDy", type: .dynamic, targets: ["Paper"]), + ], + dependencies: [ + .package(url: "http://github.com/SwiftyJSON/SwiftyJSON", from: "1.2.3"), + .package(url: "../CHTTPParser", .upToNextMinor(from: "2.2.0")), + .package(url: "http://some/other/lib", .exact("1.2.3")), + ] + targets: [ + .target( + name: "tool", + dependencies: [ + "Paper", + "SwiftyJSON" + ]), + .target( + name: "Paper", + dependencies: [ + "Basic", + .target(name: "Utility"), + .product(name: "CHTTPParser"), + ]) + ] + ) + ``` +