A Wishlist for Swift 3.0

With great improvements in Swift 2.0 such as protocol extensions and proper error handling, Apple has made it clear that they actively listen to the developer community’s wishes in shaping the future of language. We asked several dev friends using Swift what they’d most like to see in the next iteration, and they shared great ideas on improving the type system, protocols, and the tooling in the next version of Swift!


What would you like to see in Swift 3.0?

Sash Zats

Sash Zats, iOS Engineer, UX Artisan, API Craftsman at Labgoo & Wondermall

Typed Errors

My first wish is for a minor but important enhancement: typed errors. Swift 2 introduced a new error handling mechanism, but sadly it is not as strongly typed as the rest of the language. The good part of it is that error handling became part of the function signature, e.g. doSomething() and doSomething() throws are different types and you can’t use the former in place of the latter. The bad part is that doSomething() throws doesn’t express type of errors it can throw (similar to a list of protocols: throws<IOType, NetworkingError>).

Dependent Types

Secondly, I’d love to see support for dependent types. This is a concept I’m still trying to wrap my head around, but so far it seems like a very cool addition to the type system. It adds constraints on the value itself. This is how type system evolves: Untyped Array → Array of Strings → Array of Strings containing only 2 elements. It’s a handy addition to the language’s expressiveness. Here’s an example of when it might be useful:

class Car {
  var wheels: [Wheel]<4> = [Wheel(), Wheel()] 
  // compiler error, type mismatch, expected 4 wheels
}

Get more development news like this

Swift Cocoa Branch

Lastly, I’d love to see (but probably won’t) a Swift branch of Cocoa. While Cocoa is an amazing family of frameworks, it carries a lot of baggage, and probably affects the way Swift develops as a language.

I’d love to see structs where references are not needed (off the top of my head, I think classes like UIBarButtonItem, UINavigationItem, etc. do not require you to accumulate state and therefore can be replaced with structs). Thus, we could be redesigning APIs to leverage associated values in enums where possible. In some cases an enum is a more precise description of what’s happening: UIDatePicker for example can use associated enum to represent both values and the mode used to create values in one property.

class UIDatePicker {
  enum Value {
    case Date(date: NSDate)
    case CountDownTimer(period: NSTimeInterval)
  }
  var value: Value?
}

This is unlikely to happen though: this kind of change would require a huge effort by a separate team creating a new version for each existing and new API.

I’m sure some of these ideas sounds silly compared to the actual problems and long term goals the Swift team is pursuing. They are doing a great job and the community can definitely feel it!

</div>

Jorge Ortiz

Jorge Ortiz

Founder of PoWWaU, Mobile Development Instructor and Developer

Better Tooling

I would like to have a more mature set of tools. I want a debugger that I can always trust instead not just sometimes, and that is able to show me the value of a symbol that is in the current stack frame, no matter what. I want an editor that is able to do refactoring in Swift at least as well as it does it in Objective-C, so I can enhance my code with its help, extracting some statements into a method or renaming a class or a method across all my projects.

This editor should be able to generate code to save me from typing the boilerplate code (and I don’t mean snippets). For example, if the compiler is able to find out that the class or struct is not implementing all of the methods that are required for a protocol I’ve committed to use, I would like the option to have the editor do the automatic part of creating the definition of the methods that are missing.

Improved Testing

The second wish is a very simple one, but it would really make everybody who is into testing happy. I would like to have better support for running tests that don’t require the simulator. If a class depends only on Foundation, its tests should be able to be run outside of the simulator. That would reduce the time it takes to run the full suite of tests and make testing easier.

Introspection

The third one affects the language itself. I would like to have better introspection capabilities, call it reflection if you wish, and a more dynamic dispatcher. Some tools like mocking frameworks cannot be created without these features of the language.

Sam Giddins

Sam Giddins

UChicago 2018. CocoaPods. Bundler.

Higher-Kinded Types

I’m going to start off this wish for Swift 3 with an apology – you’re probably sick of hearing us highfalutin developers begging the Swift team for this feature. But I think it’s the most important feature left for them to implement, so I’m going to wish for it anyways.

Now, higher-kinded types is a loaded term, so I’m going to turn to our favorite functional programming metaphor – the burrito. We know that we can eat all burritos the same way, regardless of what’s inside of them – they’re only a container for the filling. But what if we wanted some way to tell Swift, “here, I have this object, and the only thing I care about it is that it’s a burrito. Steak, veggie, shrimp, whatever. It’s just a burrito!” Swift won’t let you do that. You need to say “all burritos that have some equatable filling are equatable.” So you look at your array burrito and implement that, and then your optional burrito…

This is all just a contrived way of saying that there’s a level of superstructure to types that Swift does not currently let us represent. There’s no way to write a definition for Monad or Functor that will work for all instances of that type – and that means for every new SequenceType we add, for example, we need to say S: Equatable when S.Element: Equatable. That gets horribly repetitive, and it means we can’t encode our actual meaning into the type system – giving us as programmers more room to make mistakes and write bugs.

Jacob Schwartz

Jacob Schwartz

Senior Engineer at Glint</div>

Xcode Decoupling

I am really happy with the evolution of the Swift language so far. I think the language team is doing an amazing job anticipating the needs of and responding to the community.

For Swift 3.0 I would love to see the language decoupled from Xcode. I haven’t been able to fully dive into Swift 2.0 because of its dependance on Xcode 7. Xcode 7 in turn drops support for iOS 7. Binding Swift versions to Xcode (and iOS SDK) versions creates unnecessary inertia that hinders adoption.

Don’t torture us with difficult tradeoffs, let us use the best language all of the time!

Viktor Belenyesi

Viktor Belenyesi

Senior iOS/Mac Developer at Prezi

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))
    }
  }
}

Agnes Vasarhelyi

Agnes Vasarhelyi

iOS/Mac Developer at Prezi

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)

Sam Ritchie

Sam Ritchie

Chief Codesplicer at CodeSplice

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.

Tony Arnold

Tony Arnold

Senior Developer at Itty Bitty Apps and The CocoaBots

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.

Benji Encz

Benji Encz

Engineer at Make School, soon joining PlanGrid

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>

Next Up: Realm Everywhere: The Realm Platform Reaches v2.0

General link arrow white

About the content

This content has been published here with the express permission of the author.


Realm Team

At Realm, our mission is to help developers build better apps faster. We provide a unique set of tools and platform technologies designed to make it easy for developers to build apps with sophisticated, powerful features — things like realtime collaboration, augmented reality, live data synchronization, offline experiences, messaging, and more.

Everything we build is developed with an eye toward enabling developers for what we believe the mobile internet evolves into — an open network of billions of users and trillions of devices, and realtime interactivity across them all.

4 design patterns for a RESTless mobile integration »

close