Accepted

SE-0068: Expanding Swift Self to class members and value types is accepted with modifications:

The review of SE-0068: “Expanding Swift Self to class members and value types” ran from April 20…25, 2016. A subset of the proposal has been *accepted*:

This proposal had light discussion in the community review process, but the core team heavily debated it.  It includes two pieces:

1. Expanding the existing support for Self to work in value types, and in the bodies of classes.
2. Replacing the x.dynamicType expression with x.Self, a purely syntactic change that eliminates the “dynamicType” keyword.

The core team has accepted the first half for this proposal.  This allows the use of “Self” as shorthand for referring to the containing type (in the case of structs, enums, and final class) or the dynamic type (in the case of non-final classes).  Most of the discussion in the core team centered around whether people familiar with the former behavior would be surprised by the (more general) behavior when using it in a class, but they came to agree that this is actually a simple and general model, and a helpful point of consistency.

In contrast, there are still a number of concerns with rebranding x.dynamicType as x.Self.  This may (or may not) be the right ultimate direction to go, but it should be split out of this proposal.  There is another outstanding proposal that would eliminate the “Type.self” syntax as being necessary, and the core team would like to resolve that discussion before tackling x.dynamicType.

A third part of the proposal, already removed, which would introduce #Self, to be replaced at compile time with the calling context for use in return types, variable types, and debug statements, will also be deferred until after the “Type.self” syntax is settled.

SE-0065: A New Model for Collections is accepted.

We propose a new model for Collections wherein responsibility for index traversal is moved from the index to the collection itself. For example, instead of writing i.successor(), one would write c.index(after: i). We also propose the following changes as a consequence of the new model:

• A collection’s Index can be any Comparable type.
• The distinction between intervals and ranges disappears, leaving only ranges.
• A closed range that includes the maximal value of its Bound type is now representable and does not trap.
• Existing “private” in-place index traversal methods are now available publicly.

SE-0066: Standardize function type argument syntax to require parentheses [ACCEPTED] in review to 5/2. “This proposal suggests that we simply eliminate the special case and require parentheses on all argument lists for function types.” I’m strongly for this one.

SE-0067: Enhanced Floating Point Protocols [ACCEPTED] enters Review #2 with incorporated feedback to 4/29. “Revision 2 reintroduces some of the details of the Arithmetic protocol from earlier drafts of this proposal, but as methods in the FloatingPoint API, with the goal of reducing the number of overloads for basic operations. This change was requested by some members of the core langauge team. Revision 2 also incorporates a number of suggestions from the review list and corrects some typos; thanks especially to Xiaodi Wu for thoughtful feedback.”

SE-0070: Make Optional Requirements Objective-C-only [ACCEPTED] in review to 5/3. “Swift currently has support for “optional” requirements in Objective-C protocols, to match with the corresponding feature of Objective-C. We don’t want to make optional requirements a feature of Swift protocols (for reasons described below), nor can we completely eliminate the notion of the language (for different reasons also described below). Therefore, to prevent confusion about our direction, this proposal requires an explicit ‘@objc’ attribute on each optional requirement to indicate that this is an Objective-C compatibility feature.”

SE-0071: Allow (most) keywords in member references [ACCEPTED] in review to 4/29. “The Swift API Design Guidelines consider enum cases as values that use the lowerCamelCase naming conventions. This means that case names that previously did not conflict with keywords (such as Default, Private, Repeat) now cause conflicts, a problem that is particularly acute when the naming conventions are applied by the Clang importer (per SE-0005). To mitigate this issue, this proposal allows the use of most keywords after a “.”, similarly to how SE-0001 allows keywords are argument labels.”

SE-0061: Add Generic Result and Error Handling to autoreleasepool() [ACCEPTED] in review to 4/26. Not to be confused with Generic Result and Error Handling in Deadpool. “The autoreleasepool function in the standard library does not currently support a return value or error handling, making it difficult and error-prone to pass results or errors from the body to the calling context.”

SE-0069: Mutability and Foundation Value Types [ACCEPTED]  in review to 5/4. This one gives “mutability when you need it” to wrap Foundation variations invisibly to Swift use.

SE-0017: Change Unmanaged to use UnsafePointer [ACCEPTED] in review to 5/3. “The standard library Unmanaged<Instance> struct provides a type-safe object wrapper that does not participate in ARC; it allows the user to make manual retain/release calls”. SE-0017 proposes to replace the use of of COpaquePointer with UnsafePointer<Void> and UnsafeMutablePointer<Void> in the Unmanaged API.

SE-0052: Change IteratorType post-nil guarantee [ACCEPTED] in review to 5/3. “Currently, the documentation for IteratorType.next() has the precondition that when calling next(), no preceding call to next() should have returned nil, and in fact encourages implementations to raise a preconditionFailure() for violations of this requirement. However, all current 27 IteratorType implementations in the standard library return nilindefinitely. Many users are likely unaware of the precondition, expecting all iterators to return nil indefinitely and writing code that might rely on this assumption. Such code will usually run fine, until someone does in fact pass in an iterator not repeating nil (it’s a silent corner case).”

SE-0032: Add find method to SequenceType [ACCEPTED]  in review to 5/3. I have personal issues with SequenceType, namely that there may non-terminating sequences. My issues have nothing to do with this proposal, which Lily clarifies: “I have seen people write code like seq.lazy.filter(predicate).first, but this doesn’t actually work lazily because .first is only a method on Collection, which means the call to filter() ends up resolving to theSequence.filter() that returns an Array instead of to LazySequenceProtocol.filter() that returns a lazy sequence. Users typically aren’t aware of this, which means they end up doing a lot more work than expected.”

SE-0045: Add scan, prefix(while:), drop(while:), and iterate to the stdlib [PARTIALLY ACCEPTED: parts returned for bikeshedding over the naming] in review to 5/3. Love the proposal. Hate the name mismatch. Either prefix/suffix or take/drop makes more sense to me. Worse, the beautiful and fairly obvious iterate is under fire and may become something like “ice ice baby” or “unfold(_:applying:)“. This review gets all the +1s, except for the naming.

SE-0072: Fully eliminate implicit bridging conversions from Swift [ACCEPTED] runs to 5/2. “In Swift 1.2, we attempted to remove all implicit bridging conversions from the language. Unfortunately, problems with how the v1.2 compiler imported various un-annotated Objective-C APIs caused us to scale back on our ambitions. In the interest of further simplifying our type system and our user model, we would like to complete this work and fully remove implicit bridging conversions from the language in Swift 3.”

In Review

• SE-0060: Enforcing order of defaulted parameters In review to 5/9. I vote no. Details at link.
• SE-0073: Marking closures as executing exactly once in review to 5/9. “This proposal introduces an optional once argument to the @noescape attribute. The @noescape(once) attribute enforces that the closure does not escape, and that it is run exactly once on any code path returning from the function. For clients, it allows the compiler to relax initialization requirements and close the gap between closure and “inline code” a little bit.”
• SE-0074: Implementation of Binary Search functions in review 5/9. “Swift does not offer any way to efficiently search sorted collections. This proposal seeks to add a few different functions that implement the binary search algorithm.”
• SE-0076: Add overrides taking an UnsafePointer source to non-destructive copying methods on UnsafeMutablePointer in review to 5/9. “UnsafeMutablePointer includes several methods to non-destructively copy elements from memory pointed to by another UnsafeMutablePointer instance. I propose adding overloads of these methods to UnsafeMutablePointer that allow an UnsafePointer source.”
• SE-0078: Implement a rotate algorithm, equivalent to std::rotate() in C++ in review to 5/9. “There are three different versions of the rotate algorithm, optimized for collections with forward, bidirectional, and random access indices. The complexity of the implementation of these algorithms makes the generic rotate algorithm a perfect candidate for the standard library.”
• SE-0080: Failable Numeric Conversion Initializers in review to 5/9. “Swift numeric types all currently have a family of conversion initializers. In many use cases they leave a lot to be desired. Initializing an integer type with a floating point value will truncate any fractional portion of the number. Initializing with an out-of-range value traps. This proposal is to add a new family of conversion initializers to all numeric types that either complete successfully without loss of information or throw an error.”

Awaiting Scheduling

• SE-0012: Add @noescape to public library API
• SE-0041: Updating Protocol Naming Conventions for Conversions (About to be scheduled)
• SE-0075: Adding a Build Configuration Import Test
• SE-0077: Improved operator declarations
• SE-0079: Allow using optional binding to upgrade self from a weak to strong reference

Like my posts? Consider buying a book or two. Thanks!