Erica Sadun

Where technology meets something or other

Swift Taxonomy: Acceptances and Rejections

SE-0060: Enforcing order of defaulted parameters IS ACCEPTED. I voted no. Team writes,

The feedback on the proposal was generally positive (several people remarked that they didn’t know this was allowed).  Some people pointed out that removal of this capability penalizes API design in cases where there is no inherent order to parameters, but this is also true of non-defaulted parameters.  The core team prefers to encourage consistency at call sites.

SE-0073: Marking closures as executing exactly once IS REJECTED “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.” Team writes,

The feedback on the proposal was generally positive both from the community and core team.  That said, it is being rejected for Swift 3 two reasons:

1) The surface level syntax of @noescape needs to be reconsidered.  At the minimum, we need to rename @noescape to @nonescaping for consistency with our previously agreed attribute naming scheme.  However, it is also work discussing whether @nonescaping should be the default: if so, the attribute should actually become @escaping, and the functionality proposed in SE-0073 would be named @once.

2) Separate from the surface level issues, the implementation underlying this work has some significant challenges that are doable but would require major engineering work.  Specifically, the definite initialization pass needs to “codegen” booleans in some cases for conditional initialization/overwrite cases, and these state values would have to be added to closure capture lists.  This would require enough engineering work that it seems unlikely that it would happen in the Swift 3 timeframe, and beyond that this could theoretically be subsumed into a more general system that allowed control-flow-like functions to have closures that break/continue/throw/return out of their enclosing function, or a general macro system.

Overall, everyone desires the ability to produce more control-flow like functions, but Swift 3 isn’t in a place where it can make sense to tackle this work.

SE-0074: Implementation of Binary Search functions IS REJECTED. “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.” Team writes,

The feedback on the proposal was generally positive about the concept of adding binary search functionality, but  negative about the proposal as written, with feedback that it was adding too much complexity to the API.

SE-0076: Add overrides taking an UnsafePointer source to non-destructive copying methods on UnsafeMutablePointer IS ACCEPTED WITH REVISION “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.” Team writes,

The feedback on the proposal from the community and the core team universally agreed that there is a problem that needs to be solved here.  However, instead of adding overloads of the methods as proposed, it would be better to change the existing methods to take UnsafePointer<> instead of UnsafeMutablePointer<>.  Given the existing promotion rules that exist in the compiler, it will achieve the same effect.  As part of this, other similar functions in the standard library should be audited and fixed as well.

SE-0080: Failable Numeric Conversion Initializers IS ACCEPTED WITH REVISIONS. “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.” Team writes,

The feedback on the proposal from the community and the core team was universally positive, and the new initializers on the primitive integer and floating point types have been approved.  However, swift-evolution isn’t the right mechanism to propose extensions to Foundation types, so the extensions that adds conversions from NSNumber and to Foundation types should be subset out of the proposal.

SE-0078: Implement a rotate algorithm, equivalent to std::rotate() in C++ AWAITS DECISION. “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.”

In Review

Awaiting Scheduling

Tweet this Post

Comments are closed.