A Wishlist for Swift 3.0

Store Properties in Extension

Like with Scala traits, it’d be great to be able to add new properties to existing classes via extensions. It is possible at the moment by objc runtime but I have a bad feeling whenever I have to type something like this:

extension UIView {
  var myTag: String? {
    get {
      return objc_getAssociatedObject(self, "myTag") as? String
    }
    set(newValue) {
      objc_setAssociatedObject(self, "myTag", newValue, UInt(OBJC_ASSOCIATION_RETAIN))
    }
  }
}

Covariance in Custom Generic Types

Built-in types are covariant already, but when it comes to creating your own Party<T>, you have to add different kind of people to the guest list by default, otherwise it’s designed to fail.

class 🎃 {}
class 👻 : 🎃 {}
class 👹 : 🎃 {}

struct Party<T> {
  let attendees:[T]
  init(attendees:[T]) {
    self.attendees = attendees
  }
}

func guestList(party:Party<🎃>) -> String {
  return party.attendees.description
}

var attendees = Party(attendees:[👻(), 👻()])
guestList(attendees)

Protocol Conformance for Constrained Generics

Swift extensions have two really useful capabilities - one is adding protocol conformance, which we had in Swift 1:

extension String: JSONEncodable {
  func toJSON() -> JSON { return .String(self) }
}

and the other is adding generic constraints to extensions, which was added in Swift 2:

extension Array where Element: JSONEncodable {
  func toJSON() -> JSON {
    return .Array(self.map { $0.toJSON() })
  }
}

Unfortunately you can’t combine the two (add protocol conformance to a constrained generic type), i.e. extension Array: JSONEncodable where Element: JSONEncodable is not possible. This means if you’re practicing ‘protocol-oriented programming’ you either need to avoid generic types or spend a lot of time & effort writing overloads. If this is implemented in Swift 3, it will save a lot of code and make protocols & generics much more useful.

I don’t have any great wants for the language itself — some kind of language-level C# Async-style functions would be great, but my biggest want is just better tooling. Editing Swift in Xcode is still a pretty laborious affair, and with the refactoring tools disabled it’s like going back in time to an IDE of ages past. Better editing tools and better errors when something goes wrong would thus be great to have.

I’d also love to see nil deprecated in place of explicitly requiring Optional.None, but that’s a conversation to be had over alcohol 🍷

I hadn’t thought about Swift 3.0 all that much to be honest. The standard library is really nice and compact, and if there’s something missing you really can (and should!) build it yourself using that.

Typed Error Handling

I’d like to see that functions that can throw declare the types of errors they can produce. The current recommendation is to include this information in the documentation of a function, but it would be great if the compiler had the type information as well. This way it would be possible to implement exhaustive error handling without a catch‑all case. It also would make the APIs of error‑producing functions more expressive.</div>