Behind the scenes: Swift core team design discussion 3/15

In the spirit of transparency, the Swift core team has posted its notes about upcoming proposals. These notes help guide the modification of existing proposal before they’re submitted to the community for an open review and give greater insight into the team’s views.

Apple’s Alex Martini writes, “These are informal comments, intended to guide the proposals in directions that draw constructive feedback. You are welcome to ignore the feedback, agree with it, or disagree with it.  As always, the formal decision doesn’t happen until after the review period ends.”

For example, in the notes about SE-0047, which changes the default behavior of Swift methods and functions to warn on unused results, you’ll note how the team considered whether the override attribute should apply to the return type.

They wrote, “We like how putting the @discardable on the type because of how it reads, but it’s not on the type.”) In the active proposal, the modifier is now  @discardableResult and it modifies the function or method. “It’s actually more semantically part of the function. You don’t have a “discardable integer”, you have a function whose result is discardable.”

Contrast that with SE-0049, which moves @noescape and @autoclosure to decorate types. “In short, @noescape and @autoclosure are attributes on the parameter. We got away with it before, but now that we’re requiring you to manually uncurry, you can’t write things that you used to be able to write. None of this makes sense; we should only accept these attributes in the type position.”

Some interesting (short) comments as well on SE-0042 (Flattening Method types), SE-0043 (Variables in Case Labels), and SE-0048 (Generic Typealiases).

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

One Comment

  • While I absolutely agree with the idea, the implementation in the 05-31 snapshot of this breaks method chaining (like `socket.send(“x”).send(“y)”`). One can mark relevant methods as @discardableResult, but this will still result in a `expression of type N is unused` as a follow-up error.