How Swift 3.1 is different from earlier version? – Part 1

On June 12th, 2017 in iOS Development, iOS Programming, iPhone, iPhone Development, Mobile Development, Objective-C
As most of the developers know that Swift is a general-purpose programming language. It is built using a modern approach to safety, performance, and software design patterns. And if you are already an iOS developer, you are already familiar with these things!

Source

Recently, a beta version of Xcode 8.3 and Swift 3.1 was released with Swift Package Manager features and improvements to the language. In this article we will majorly discuss about the Language improvements, rest will be covered in other part of the article. Let us check out the most significant features and changes in Swift 3.1 as it will have a major impact on your code!

Also Read:Swift 3.1: Swift Package Manager – Part 2

Introduction

Swift 3.1 has downward compatibility, a person can work on lower versions codes of Swift. All you need to do is to migrate your project to Swift 3.0 using Edit\Convert\To Current Swift Syntax in Xcode. Start Xcode, select File-> New-> Playground. Choose iOS as the platform, you can call it whatever you want, and save it wherever you want.

Language Improvements

There are a number of languages improvements in this release. It includes failable initializers for numeric types, new sequence functions, and more. Let us check them out-

1. Failable Numeric Conversion Initializers

The new version implements failable initializers for all numeric types such as Int, UInt, Float, Double, etc. It either completes successfully without losing any information or simply returns NIL. This feature helps while dealing with loosely typed data conversion from external sources in a safe and recoverable manner. Just check it out by processing this JSON code-
  1. class Student {
  2.  let name: String
  3.  let grade: Int
  4.  
  5.  init?(json: [String: Any]) {
  6.    guard let name = json[“name”] as? String,
  7.          let gradeString = json[“grade”] as? String,
  8.          let gradeDouble = Double(gradeString),
  9.          let grade = Int(exactly: gradeDouble)  // <– 3.1 feature here
  10.    else {
  11.        return nil
  12.    }
  13.    self.name = name
  14.    self.grade = grade
  15.  }
  16. }
  18. func makeStudents(with data: Data) -> [Student] {
  19.  guard let json = try? JSONSerialization.jsonObject(with: data, options: .allowFragments),
  20.        let jsonArray = json as? [[String: Any]] else {
  21.    return []
  22.  }
  23.  return jsonArray.flatMap(Student.init)
  24. }
 
  1. let rawStudents = “[{\”name\”:\”Ray\”, \”grade\”:\”5.0\”}, {\”name\”:\”Matt\”, \”grade\”:\”6\”},
  2.                    {\”name\”:\”Chris\”, \”grade\”:\”6.33\”}, {\”name\”:\”Cosmin\”, \”grade\”:\”7\”},
  3.                    {\”name\”:\”Steven\”, \”grade\”:\”7.5\”}]”
  4. let data = rawStudents.data(using: .utf8)!
  5. let students = makeStudents(with: data)
  6. dump(students) // [(name: “Ray”, grade: 5), (name: “Matt”, grade: 6), (name: “Cosmin”, grade: 7)]
Here, failable initializer is used to convert the grade property from Double to Int inside the Student class.
let grade = Int(exactly: gradeDouble)
If gradeDouble is a fractional value, it will fail. It will succeed only if the value can be represented exactly as an integer.

Also Read:Kotlin- The Next-Gen Android App Development Language

2. New Sequence Functions

There are two new functions for data filtering to the standard library’s Sequence protocol- prefix(while:) and drop(while:). Consider the Fibonacci infinite sequence:
  1. let fibonacci = sequence(state: (0, 1)) {
  2.  (state: inout (Int, Int)) -> Int? in
  3.  defer {state = (state.1, state.0 + state.1)}
  4.  return state.0
  5. }
  Swift 3.0 simply specify the iteration count to iterate through the Fibonacci sequence-
  1. // Swift 3.0
  2. for number in fibonacci.prefix(10) {
  3.  print(number)  // 0 1 1 2 3 5 8 13 21 34
  4. }
Swift 3.1 lets you use prefic(while:) and drop(while:) with a condition to get all the elements of the sequence between two given values.
  1. // Swift 3.1
  2. let interval = fibonacci.prefix(while: {$0 < 1000}).drop(while: {$0 < 100})
  3. for element in interval {
  4.  print(element) // 144 233 377 610 987
  5. }
In the code, prefix(while:) returns the longest sub-sequence which satisfies a certain predicate. while drop(while:) does the opposite.  

3. Concrete Constrained Extensions

Swift 3.1 extended generic type with a concrete type constraint. Previously, it could not extend a type like this due to protocol constraint. Example- Ruby on Rails provides isBlank method for checking for user input. Let us check out how it would be implemented in Swift 3.0 as a computed property on the String data type extension:
  1. // Swift 3.0
  2. extension String {
  3.  var isBlank: Bool {
  4.    return trimmingCharacters(in: .whitespaces).isEmpty
  5.  }
  6. }
  8. let abc = ” “
  9. let def = “x”
  11. abc.isBlank // true
  12. def.isBlank // false
If you want the isBlank computed property to work with optional strings as well, you would do the following in Swift 3.0:
  1. // Swift 3.0
  2. protocol StringProvider {
  3.  var string: String {get}
  4. }
  6. extension String: StringProvider {
  7.  var string: String {
  8.    return self
  9.  }
  10. }
  12. extension Optional where Wrapped: StringProvider {
  13.  var isBlank: Bool {
  14.    return self?.string.isBlank ?? true
  15.  }
  16. }
  18. let foo: String? = nil
  19. let bar: String? = ”  “
  20. let baz: String? = “x”
  22. foo.isBlank // true
  23. bar.isBlank // true
  24. baz.isBlank // false
Swift 3.1 lets you extend a concrete type instead of a protocol like this:
  1. // Swift 3.1
  2. extension Optional where Wrapped == String {
  3.  var isBlank: Bool {
  4.    return self?.isBlank ?? true
  5.  }
  6. }
It is better than earlier versions because it does the same work in fewer lines.

4. Nested Generics

The new version allows you to mix nested types with generics. Understanding it with an example would be easier when an article is posted on a website, the actual coding behind looks like this-
  1. class Team<T> {
  2.  enum TeamType {
  3.    case swift
  4.    case iOS
  5.    case macOS
  6.  }
  7.  
  8.  class BlogPost<T> {
  9.    enum BlogPostType {
  10.      case tutorial
  11.      case article
  12.    }
  13.    
  14.    let title: T
  15.    let type: BlogPostType
  16.    let category: TeamType
  17.    let publishDate: Date
  18.    
  19.    init(title: T, type: BlogPostType, category: TeamType, publishDate: Date) {
  20.      self.title = title
  21.      self.type = type
  22.      self.category = category
  23.      self.publishDate = publishDate
  24.    }
  25.  }
  26.  
  27.  let type: TeamType
  28.  let author: T
  29.  let teamLead: T
  30.  let blogPost: BlogPost<T>
  31.  
  32.  init(type: TeamType, author: T, teamLead: T, blogPost: BlogPost<T>) {
  33.    self.type = type
  34.    self.author = author
  35.    self.teamLead = teamLead
  36.    self.blogPost = blogPost
  37.  }
  38. }
  We nest BlogPost inner class within Team outer class and make both classes generic. And this is how it looks like-
  1. Team(type: .swift, author: “Cosmin Pupăză”, teamLead: “Ray Fix”,
  2.     blogPost: Team.BlogPost(title: “Pattern Matching”, type: .tutorial,
  3.     category: .swift, publishDate: Date()))
  5. Team(type: .swift, author: “Cosmin Pupăză”, teamLead: “Ray Fix”,
  6.     blogPost: Team.BlogPost(title: “What’s New in Swift 3.1?”, type: .article,
  7.     category: .swift, publishDate: Date()))
  Whereas it could be simplified. Nested inner type can inherit the parent’s class type by default if the nested inner type uses the generic outer one. Therefore you don’t have to declare it, like so:
  1. class Team<T> {
  2.  // original code
  3.  
  4.  class BlogPost {
  5.    // original code
  6.  }  
  7.  
  8.  // original code
  9.  let blogPost: BlogPost
  10.  
  11.  init(type: TeamType, author: T, teamLead: T, blogPost: BlogPost) {
  12.    // original code   
  13.  }
  14. }

5. Convert Non-Escaping Closures to Escaping Ones

In Swift 3.0, closure arguments were made non-escaping to function by default, while you can convert non-escaping closures to escaping ones temporarily by using withoutActuallyEscaping() helper function in Swift 3.1. Let us understand this with an example-
  1. func perform(_ f: () -> Void, simultaneouslyWith g: () -> Void,
  2.             on queue: DispatchQueue) {
  3.  withoutActuallyEscaping(f) { escapableF in     // 1
  4.    withoutActuallyEscaping(g) { escapableG in
  5.      queue.async(execute: escapableF)           // 2
  6.      queue.async(execute: escapableG)     
  7.      queue.sync(flags: .barrier) {}             // 3
  8.    }                                            // 4
  9.  }
  10. }
This function runs two closures simultaneously and then returns when both are done.
  1. f and g come in as non-escaping and are converted to escapableF and escapableG.
  2. async(execute:) calls require escaping closures. Fortunately, you have those because of the previous step.
  3. By running sync(flags: .barrier), you ensure that the async(execute:) methods are completely done and the closures won’t be called later on.
  4. Scope limits the use of escapableF and escapableG.
If you squirrel either temporary escaping closures away (i.e. actually escaped them) it would be a bug. There are many other changes in Swift 3.1. They include Swift Package Manager Updates, Multiple-Return Functions, Disable Auto-Linking, etc. We will be discussing it in next part. Till then share your views with use!