Welcome to issue #25!

Starter tasks

• SR-1615: CoreFoundation should be audited for platform and architecture switches
• SR-1608: NSStream, NSInputStream, and NSOutputStream need implementations
• SR-1602: NSEnergyFormatter needs to be implemented

Submit a task by sending a pull request or opening an issue.

Commits and pull requests

Slava Pestov finished adding support in SILGen for nested generic functions. His update to the changelog provides an example of the new functionality that this enables.

Trent Nadeau completed the final part of the implementation for SE-0047, removing @warn_unused_result and adding a fixit.

Robert Widmann merged a pull request to provide a better diagnostic for nil comparisons when attempting to use === for value types.

Nate Cook fixed an error in the nextUp and nextDown implementation.

Chris Williams opened a pull request to implement SE-0080: Failable Numeric Conversion Initializers.

Robert Widmann fixed an off-by-one error in the @noescape fixit.

Accepted proposals

Max Moiseev’s proposal, SE-0093: Adding a public base property to slices, was accepted for Swift 3.

There was little feedback from the community other than to get clarification. The core team recognizes the proposal as exposing an important basis operation of slice types.

Erica Sadun’s proposal, SE-0096: Converting dynamicType from a property to an operator, was accepted with revision.

The feedback on the community on the proposal was very light, but there were significant concerns about its name. After discussion, the core team agrees that x.dynamicType should use the syntax of a global function as stated by the proposal, but would prefer for that function to be spelled type(of: x) to follow the naming guidelines. The rationale is:

• The function is side-effect free, so it should have a noun that describes what is returned.
• “type” is ambiguously a noun, verb, and perhaps other things, so the “of” preposition is necessary for clarity.

Returned proposals

Erica Sadun’s and Xiaodi Wu’s proposal, SE-0050: Decoupling Floating Point Strides from Generic Implementations, was returned for revision.

There was very little feedback from the community — the feedback was positive about solving the floating point error accumulation problem indicated by the proposal, but wasn’t strongly positive about the solution. The core team also agrees that the problem needs to be solved, however they don’t think this API change is the right approach. […] Once the design of this iterates on swift-evolution, it would be great to see a revised version of this proposal.

Adrian Zubarev’s and Austin Zheng’s proposal, SE-0095: Replace protocol<P1,P2> syntax with Any<P1,P2>, was returned for revision, with the intent that the revised proposal will be included for Swift 3. I recommend following the link to read Chris Lattner’s full response.

There was an incredible amount of feedback from the community, continuing even today. The principle problem identified by community about the proposal is that Any<T1, T2> implies very strongly an “any of T1 OR T2” relationship (aka disjunction) and not “any type conforming to T1 AND T2” relationship (aka conjunction). There was also some related discussion as to how the Any<> syntax aligns with future generalized existential syntax, much discussion as to whether it should be spelled Any<> or any<>, and some discussion about “angle bracket blindness”.

The core team extensively discussed the feedback and considered many different possible paths forward. The conclusion of this is that it recommends that SE-0095 be revised into a fairly different proposal, one that introduces a new infix & type operator for representing protocol and other type compositions…

Rejected proposals

Proposal SE-0098: Lowercase didSet and willSet for more consistent keyword casing was rejected.

The feedback on the proposal from both the core team and the community was that these should remain camel cased, particularly given that they may become user-definable aspect names in a future release.

Proposal SE-0097: Normalizing naming for “negative” attributes was rejected for Swift 3.

The core team agrees with the principle guiding the proposal (that negative attributes should start with “non” instead of “no”) and highly values standardized naming for attributes. The community was lukewarm about “nonescaping” but pretty significantly opposed to “nonreturning”.

The core team discussed this at length and agreed that the problem identified by the proposal needs to be solved, but prefers to explore directions that would define away these attributes completely:

1. For noreturn, the core team prefers to explore a solution where a function can be declared as returning an non-constructable “bottom” type (e.g. an enum with zero cases). This would lead to something like: func abort() -> NoReturn { … }. This will require some new support in the compiler, but should flow better through the type system than @noreturn in function composition and other applications. Joe Groff offered to write a proposal for this.

2. For @noescape, the core team feels that the right solution is for closure arguments to default to @noescape, which means that the attribute we should really need is @escaping.

Proposals in review

Erica Sadun’s and Chris Lattner’s proposal, SE-0099: Restructuring Condition Clauses, is under review.

Swift condition clauses appear in guard, if, and while statements. This proposal re-architects the condition grammar to enable an arbitrary mix of Boolean expressions, let conditions (which test and unwrap optionals), general case clauses for arbitrary pattern matching, and availability tests. It removes where clauses from optional binding conditions and case conditions, and introduces semicolons (optionally newlines) between unrelated condition types rather than commas, which are reserved for continuation lists. This eliminates ambiguity problems in the current syntax, and alleviates the situation where many Swift developers don’t know they can use arbitrary Boolean conditions after a value binding.

Mailing lists

Harlan Haskins pitched an idea about introducing a #warning compiler directive that would emit a warning diagnostic. This would serve a similar purpose as a // TODO or // FIXME comment, but produce an actual warning in Xcode. Jordan Rose gave a +1 to the proposal, noting how this could have a positive impact outside of IDEs like Xcode, for example with SwiftPM.

Tony Allevato drafted a proposal for automatically deriving Equatable and Hashable for certain value types. It’s an interesting idea, but certainly has challenging edge cases. There was some discussion over adding specific keywords to include or exclude which properties of a type are used in the Equatable and Hashable definitions, but this seems overly complicated. Becca Royal-Gordon warned early on to keep it simple. Patrick Smith suggested providing implementations by default, and allowing users to override.

Erica Sadun pitched an idea about adding a with function to the standard library to address a common situation where developers want to duplicate and modify a constant value type (without having to use var). (Gist here) Example:

// Before
let john = Person(name: "John", favoriteColor: .blueColor())
let jane: Person = { var copy = $0; copy.name = "Jane"; return copy }(john)

// After
let jane = with(john) { $0.name = "Jane" }

Austin Zheng started a discussion on property reflection. “For those who are interested I’d like to present a pre-pre-proposal for reflection upon a type’s properties and solicit feedback. First of all, some caveats: this is only a very small piece of what reflection in Swift might look like one day, and it’s certainly not the only possible design for such a feature.” Here’s the gist of a rough, possible “KVC-like” API. Somebody tell Brent Simmons and Chris Eidhof. 😄

David Rönnqvist started a discussion on the difference between how static and lazy variables are evaluated when initially assigned with a different value. Briefly, stored properties evaluate first before assigning a new value, but lazy properties do not.

Finally

And finally — Did you ever realize that UIViewController has troll in its name? 😂 It might be the biggest troll in all of UIKit. 😉