SE-0087: Rename lazy to @lazy in review to 5/23. “Swift’s rule for attribues/keywords is that keywords usually modify type of variable; attributes do not. lazy clearly does not modify type of its variable, it only delays side effects of its initializer. Type of resource in the example above is still NSData. Many other similar declaration modifiers are already attributes including @available, @objc, @nonobjc, @NSCopying, @NSManaged, @IBOutlet, etc.”

SE-0077: Improved operator declarations in review to 5/23. SE-0077 introduces general precedence that isn’t numerically based. “In the beginning, operators had nice precedence values: 90, 100, 110, 120, 130, 140, 150, 160. As time went, new and new operators were introduced. Precedence could not be simply changed, as this would be a breaking change. Ranges got precedence 135, as got precedence 132. ?? had precedence greater than <, but less than as, so it had to be given precedence 131. Now it is not possible to insert any custom operator between < and ??. It is an inevitable consequence of current design: it will be impossible to insert an operator between two existing ones at some point.”

SE-0091: Improving operator requirements in protocols in review to 5/23. “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).”

SE-0090: Remove .self and freely allow type references in expressions in review to 5/23. “Swift’s grammar currently requires that type references only appear as part of a constructor call T(x) or member access T.x. To get the metatype object for T, one must refer to the special member T.self. I propose allowing type references to appear freely in expressions and removing the .self member from the language.”

SE-0089: Renaming String.init<T>(_: T) in review to 5/23. “Swift’s String type ships with a large number of initializers that take one unlabeled argument. One of these initializers, defined as init<T>(_: T), is used to create a string containing the textual representation of an object. It is very easy to write code which accidentally invokes this initializer by accident, when one of the other synonymous initializers was desired. Such code will compile without warnings and can be very difficult to detect.”

SE-0050: Decoupling Floating Point Strides from Generic Implementations in review to 5/23. “Swift strides create progressions along “notionally continuous one-dimensional values” using a series of offset values. This proposal supplements Swift’s generic stride implementation with separate algorithms for floating point strides that avoid error accumulation.” Another step in fixing Swift Floating points.

Accepted

SE-0092: Typealiases in protocols and protocol extensions is accepted. “In Swift versions prior to 2.2, the typealias keyword was used outside of protocols to declare type aliases and in protocols to declare associated types. Since SE-0011 and Swift 2.2, associated type now use the associatedtypekeyword and typealias is available for implementing true associated type aliases.”

Chris Lattner notes:

The new proposal for SE-0092 “Typealiases in protocols and protocol extensions” is proactively approved for Swift. The core team consider this as an obvious follow-on to SE-0011, and thus doesn’t itself demand a proposal. However, including a proposal in the swift-evolution archive does have a benefit to keep track of the new capability it enables.

The core team accepted this without a formal review period (because it its obviousness) as an attempt to optimize process. If there are any serious concerns, please raise them and we are happy to reconsider and start a normal review cycle.

SE-0085: Package Manager Command Names is accepted, with original naming. “This is a proposal for changing the command names used for invoking the Swift package manager. Instead of hanging all functionality off of swift build and swift test, we will introduce a new swift package command with multiple subcommands. swift build and swift test will remain as top-level commands due to their frequency of use.”

Daniel Dunbar writes:

The Swift package manager core team met last week to discuss this proposal, and we ultimately *accepted* it relatively unchanged. I have amended the proposal to include more information on the alternatives discussed:
https://github.com/apple/swift-evolution/blob/master/proposals/0085-package-manager-command-name.md

We discussed at length the `spm` and `swiftpm` alternatives raised on this thread. In the end, we chose not to go that direction with the proposal for the reasons I included. We do recognized the desire for a shorter command, and view having an alias as something that can be added later if it proves to be the right thing to do.