Accepted

SE-0110: Distinguish between single-tuple and multiple-argument function types is accepted. “Swift’s type system should properly distinguish between functions that take one tuple argument, and functions that take multiple arguments. The current behavior violates the principle of least surprise and weakens type safety, and should be changed.” Team writes:

The community and core team agree that this proposal is the right thing to do, and many agree that this could probably have been treated as a bug fix on a previous proposal.

SE-0011: Remove type system significance of function argument labels is accepted. “Swift’s type system should not allow function argument labels to be expressed as part of a function type.” Team writes:

The community and core team agree that this proposal will lead to a simplification and clarification of the type system, as well as a more clear user model for parameter labels.  In response to community feedback, the core team is accepting the proposal with a revision to allow “purely cosmetic” parameter labels in closure types for documentation (as outlined in the alternatives section).  The core team also wants to clarify that a call to a value of closure type would not allow use of any parameter labels, some interpretations thought that “arbitrary” parameter labels could be used.

SE-0113: Add integral rounding functions to FloatingPoint is accepted. “The standard library lacks equivalents to the floor() and ceil() functions found in the standard libraries of most other languages. Currently, we need to import Darwin or Glibc in order to access the C standard library versions. In general, rounding of floating-point numbers for predictable conversion in to integers is something we should provide natively.” Team writes:

The community and core team agree that this proposal helps to “round out” the other Swift 3 numerics work. One minor revision is necessary to make the proposal implementable in Swift 3. Since protocol requirements cannot currently have default arguments, the desired behavior should be achieved with two overloads of each operation:

protocol FloatingPoint {
...
/// Returns a rounded representation of `self`, according to the specified rounding rule.
func rounded() -> Self
func rounded(_ rule: RoundingRule) -> Self

/// Mutating form of `rounded`.
mutating func round()
mutating func round(_ rule: RoundingRule)
}

Where the no argument cases can be implemented with a protocol extension that forwards to the single-argument versions.

SE-0077: Improved operator declarations is accepted. (1st version) “Replace syntax of operator declaration, and replace numerical precedence with partial ordering of operators” However many reviews it takes, this is a good one to get right. Team writes,

This round of feedback focused on naming, both of the attributes for precedence groups and the conventions to use for naming the groups themselves:

The community expressed a strong preference for ‘higherThan’ and ‘lowerThan’ precedence relationships over the previously-proposed ‘strongerThan’ and ‘weakerThan’, and the core team *agrees* that these are better terms of art. The proposal is accepted with these terms revised.

The standard library team reviewed the proposed names for the standard precedence groups, and suggests the following minor naming revisions:

• AssignmentPrecedence
• TernaryPrecedence
• DefaultPrecedence
• LogicalDisjunctionPrecedence
• LogicalConjunctionPrecedence
• ComparisonPrecedence
• NilCoalescingPrecedence
• CastingPrecedence
• RangeFormationPrecedence
• AdditionPrecedence
• MultiplicationPrecedence
• BitwiseShiftPrecedence

establishing a convention of <Noun>Precedence for precedence group names. The core team accepts the proposal with these revised standard precedence names.

Rejected

SE-0108: Remove associated type inference is rejected. “To simplify the compiler and typechecker, we propose to remove associated type witness inference [to] decreases the complexity of the type checker. Doing so removes the only aspect of Swift that depends upon global type inference. Simplifying the type checker makes it easier to improve the performance and correctness of the type checker code. Given that both are widely acknowledged issues with current versions of Swift, any opportunity for improvement should be carefully considered.” Team writes:

The community and core team agree that removing this feature will impose an unacceptable user experience regression for developers using Swift generics, including important protocols like Collection.  While we all seek the simplifications to the compiler internals that the proposal would allow, we will have to consider other approaches to achieving that in subsequent releases.

Active Review

• May 9…16 SE-0086: Drop NS Prefix in Swift Foundation “As part of Swift 3 API Naming and the introduction of Swift Core Libraries, we are dropping the NS prefix from key Foundation types in Swift.”
• July 7…12 SE-0091: Improving operator requirements in protocols (Second review) “When a type conforms to a protocol that declares an operator as a requirement, that operator must be implemented as a global function defined outside of the conforming type. This can lead both to user confusion and to poor type checker performance since the global namespace is overcrowded with a large number of operator overloads. This proposal mitigates both of those issues by proposing that operators in protocols be declared statically (to change and clarify where the conforming type implements it) and use generic global trampoline operators (to reduce the global overload set that the type checker must search).”
• June 28 … July 10 SE-0107: UnsafeRawPointer API “Swift enforces type safe access to memory and follows strict aliasing rules. However, code that uses unsafe APIs or imported types can circumvent the language’s natural type safety.” This extensive redesign addresses many issues under the microscope.
• June 28 … July 4 SE-0109: Remove the Boolean protocol “For legacy and historical reasons Swift has supported a protocol named Boolean for abstracting over different concrete Boolean types. This causes problems primarily because it is pointless and very confusing to newcomers to Swift: is quite different than Bool, but shows up right next to it in documentation and code completion. Once you know that it is something you don’t want, you constantly ignore it. Boolean values are simple enough that we don’t need a protocol to abstract over multiple concrete implementations.”
• June 30 … July 4 SE-0112: Improved NSError Bridging “Swift bridges between ErrorProtocol-conforming types and NSError so, for example, a Swift enum that conforms toErrorProtocol can be thrown and will be reflected as an NSError with a suitable domain and code. Moreover, an NSError produced with that domain and code can be caught as the Swift enum type, providing round-tripping so that Swift can deal in ErrorProtocol values while Objective-C deals in NSError objects. However, the interoperability is incomplete in a number of ways, which results in Swift programs having to walk a careful line between the ErrorProtocol-based Swift way and the NSError-based way. This proposal attempts to bridge those gaps.”
• July 1…7 SE-0114: Updating Buffer “Value” Names to “Header” Names  “This proposal updates parameters and generic type parameters from value names to header names for ManagedBuffer, ManagedProtoBuffer, and ManagedBufferPointer. All user-facing Swift APIs must go through Swift Evolution. While this is a trivial API change with an existing implementation, this formal proposal provides a paper trail as is normal and usual for this process.”
• July 1…7 SE-0115: Rename Literal Syntax Protocols “This proposal renames the *LiteralConvertible protocols to ExpressibleBy*Literal.” (I proactively changed the ExpressibleAs to ExpressibleBy in this description. It is not part of the original proposal but it makes the rename comprehensible.)
• July 5…11 SE-0116: Import Objective-C id as Swift Any type “Objective-C interfaces that use id and untyped collections should be imported into Swift as taking the Any type instead of AnyObject.”
• July 5…11 SE-0117: Default classes to be non-subclassable publicly “Since Swift 1, marking a class public provides two different capabilities: it allows other modules to instantiate and use the class, and it also allows other modules to define subclasses of it. This proposal suggests splitting these into two different concepts. This means that marking a class public allows the class to be used by other modules, but does not allow other modules to define subclasses. In order to subclass from another module, the class would be marked subclassable. Relatedly, Swift also conflates two similar concepts for class members (methods, properties, subscripts): public means that the member may be used by other modules, but also that it may be overriden by subclasses. This proposal introduces a new overridable modifier, which is used instead of public on members that are overridable.”
• July 5…11 SE-0118: Closure Parameter Names and Labels “We propose a revision to the names and argument labels of closure parameters in standard library APIs.” I unleashed the full force of my opinion on this one, I’m pretty happy with the proposed renames.