Swift Community Survey: What do we expect Swift 3.0 to look like?

[[155457]]

With the release of powerful new features such as protocol extensions and error handling in Swift 2.0, Apple has made it clear that they are actively listening to the developer community to help improve and enhance the language. We surveyed several Swift developers and asked them what they hope for the next version of Swift, so they will share their thoughts with us on the type system, protocols, and tools.

Sash Zats

iOS engineer, user experience designer and API architect at Labgoo and Wondermall

Typed Errors

My first hope is typed errors. Although this idea is still immature, it can greatly improve error handling. Swift 2 introduces a new error handling mechanism, but unfortunately, unlike other structures in the language, the error structure is not type-safe. The advantage of this is that error handling becomes part of the function signature. For example, the types of do something() and do something() throws are not the same, and the former cannot be used instead of the latter; the disadvantage is that dosomething() throws cannot specify the error types it can throw (just like the protocol list: throws<IOTypes, NetworkingError>).

Dependency Type

My second expectation is to provide support for "dependent types". This idea has not yet been fully formed in my mind, but I am sure it will bring a brand new and wonderful experience to the existing type system! It will add restrictions to the value type itself, and the type system will parse it as: untyped array -> string array -> string array with only 2 elements. This is an extremely useful supplement to the existing language. The following example illustrates where this feature is useful:

 class Car {
 var wheels: [Wheel]< 4 > = [Wheel(), Wheel()]
 // Compile error, type mismatch, 4 Wheel types are required  
 }

Swift for Cocoa

***, I hope to see (but it is unlikely to happen) a Swift fork of Cocoa. Although Cocoa is a great set of frameworks, it carries too much content and may affect the way Swift is developed.

I'd love to see structs that don't require references become commonplace in the new branch (in my imagination, I think classes like UIBarButtonItem, UINavigationItem shouldn't need you to accumulate their state, so they can be replaced with structs). As a result, we can redesign the API to take advantage of the associated values ​​in enumerations whenever possible. In some cases, enumerations can more accurately describe what they do: for example, UIDatePicker can use an associated enumeration in a single property to represent both its date value and the mode used to create the value.

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

This is unlikely to happen, though, as such a change would require a separate team to build a completely new version of both the existing and new APIs, a process that would require significant effort.

I know that these ideas of mine are very naive relative to the actual problems and long-term goals the Swift team is facing, because the entire community knows that what they are doing is awesome!

Jorge Ortiz

Founder of PoWWaU, mobile developer and teacher

Better accessibility tools

I hope to have a more mature set of auxiliary tools. For example, I hope to have a debugger that I can always trust, instead of a thing that makes mistakes from time to time. This debugger can display the actual value of a symbol in the current stack frame. In addition, I also hope to have an editor that can refactor Swift, just like in Objective-C, so that I can improve my code with its help, such as extracting some statements into methods, or renaming the name of a class or method in the project.

This editor needs to be able to generate code to save me from coding cliches (I don’t mean code snippets). For example, if the compiler finds that my class or struct does not fully implement a certain protocol, I would like to have an option to let the editor automatically create the missing methods in the definition.

Complete testing

The second wish is very simple, but it will make people who do testing really happy. I hope to run tests without the simulator, which will improve the user experience. If a class is based only on Foundation, then it should be possible to test it without the simulator. This will reduce the test suite that needs to be run, making the test time shorter.

Introspection Mechanism

The third wish concerns the language itself. I want Swift to have better introspection capabilities, or reflection if you will. In addition, I want it to have a more dynamic dispatch mechanism. Without these features, tools such as Mocking frameworks cannot be created.

Sam Giddins

UChicago 2018. CocoaPods. Bundler.

Higher-order generic types

First of all I need to apologize to everyone because you may be disgusted that we proud developers need to beg the Swift team for the new features we want in Swift 3. But I think implementing this feature is the most important thing, so I will do it no matter what.

Since high-kinded types are a hard thing to understand, I'm going to use our favorite functional programming metaphor - the burrito to explain it to you. We know that we can eat all kinds of burritos in the same way, no matter what's inside, because the burrito itself is just a wrapper for the filling inside. But if we have a method that tells Swift, "Here is an object, the only thing I care about is that it is a burrito, whether it is rolled with steak or vegetables or shrimp, I only care that it is a burrito." However, Swift can't let you do it easily. If you want to eat a burrito, you first need to do this: "Burritos with the same fillings are the same." In this way, you will find that the number of burritos you can use is very small...

We're reluctant to say that Swift's current superstructure types don't allow us to express this. There's no way to write a definition of Monad or Functor that works across all instances of that type, which means that every new SequenceType we add, for example, must be expressed as S: Equatable when S.Element: Equatable. This leads to a terrible amount of code duplication, which means we can't encode our true intentions into the type system, leading to more mistakes and bugs for us programmers.

Jacob Schwartz

Glint *** Engineer

Unlink Xcode and Swift versions

I've enjoyed watching the Swift language evolve so far, and I think the Swift team is doing an amazing job anticipating our needs and responding to public feedback.

For Swift 3.0, I was eager to be able to use the language from different versions of Xcode. I was not able to fully explore Swift 2.0 because it was only available in Xcode 7, which dropped support for iOS 7. Tying Xcode (and the iOS SDK) to Swift versions creates unnecessary inertia and prevents developers from migrating to the new syntax.

So don't make it difficult for us to choose, let us be able to use the best language at all times!

Viktor Belenyesi

Prezi *** iOS/Mac Developer

Storage properties in extensions

Just like Scala features, it would be a huge improvement if we could add new stored properties to existing classes through extensions. We can use the ObjC runtime to do this, but this code makes me feel bad because I have to type this kind of weird stuff every time:

 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

Prezi iOS/Mac Developer

Covariance in custom generic types

The built-in types in Swift are already covariant, but when it comes to creating your own Party, you generally have to add different people to the guest list, otherwise the design will fail.

Sam Ritchie

CodeSplice***Codesplicer

Constraining generic protocol conformance

Swift extensions have two very useful functions. One is the ability to increase protocol conformance. For example, in Swift 1:

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

Another is the ability to add generic constraints to protocols, for example 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 constrained generic types), for example: extension Array: JSONEncodable where Element: JSONEncodable This won't compile. This means that if you're trying to use "protocol-oriented programming", you not only need to avoid using generics, but also spend a lot of time and effort writing overloaded functions. If this feature can be implemented in Swift 3, I believe it will save a lot of code and make protocols and generics more useful.

*** Developer of Itty Bitty Apps and The CocoaBots

I don't have high expectations for the language itself, but it would be great if there were asynchronous-style functions like C#. But what I want to see most is better auxiliary tools. Using Swift in Xcode is still a pain. For example, I can't use refactoring, which makes me feel like I'm using an IDE from decades ago. It would be great if there were better tools and clearer error prompts.

Likewise, I'd like to see nil disabled where Optional.None is clearly needed, but that sounds like a suggestion I'd make while drunk.

To be honest, I haven't really thought about what Swift 3.0 will look like. The standard library is already very nice and concise, and if it's missing something, you can actually build it yourself.

Benji En cz

Make School Engineer, about to join PlanGrid

Typed error handling

What I'd like to see most is that functions can throw the types of errors they can generate. Currently Apple's recommendation is to write these error types in the function documentation, but wouldn't it be better if the compiler also knew about these error types? This would allow for precise error handling instead of using a catch-all error capture. This would also allow functions in the API that can generate errors to better express themselves.