What’s new in Swift 5.6? – Hacking with Swift

Swift 5.6 introduces one other barrage of recent options to the language, whereas refining others as we get nearer to Swift 6. On this article I wish to introduce you to the foremost modifications, offering some hands-on examples alongside the best way so you may see for your self what’s altering.

Sponsor Hacking with Swift and reach the world’s largest Swift community!

Introduce existential any

SE-0335 introduces a brand new any key phrase to mark existential sorts, and though which may sound esoteric please don’t skip forward: this one is an enormous change, and is prone to break numerous Swift code in future variations.

Protocols permit us to specify a set of necessities that conforming sorts should adhere to, reminiscent of strategies they need to implement. So, we frequently write code like this:

protocol Automobile 
    func journey(to vacation spot: String)


struct Automobile: Automobile 
    func journey(to vacation spot: String) 
        print("I am driving to (vacation spot)")
    


let car = Automobile()
car.journey(to: "London")

It’s additionally potential to make use of protocols as generic sort constraints in capabilities, which means that we write code that may work with any sort of information that conforms to a specific protocol. For instance, this can work with any sort of sort that conforms to Automobile:

func journey<T: Automobile>(to locations: [String], utilizing car: T) 
    for vacation spot in locations 
        car.journey(to: vacation spot)
    


journey(to: ["London", "Amarillo"], utilizing: car)

When that code compiles, Swift can see we’re calling journey() with a Automobile occasion and so it is ready to create optimized code to name the journey() perform immediately – a course of often called static dispatch.

All this issues as a result of there’s a second approach to make use of protocols, and it seems similar to the opposite code we’ve used to this point:

let vehicle2: Automobile = Automobile()
vehicle2.journey(to: "Glasgow")

Right here we’re nonetheless making a Automobile struct, however we’re storing it as a Automobile. This isn’t only a easy matter of hiding the underlying data, however as an alternative this Automobile sort is an entire different factor known as an existential sort: a brand new information sort that is ready to maintain any worth of any sort that conforms to the Automobile protocol.

Vital: Existential sorts are completely different from opaque sorts that use the some key phrase, e.g. some View, which should all the time characterize one particular sort that conforms to no matter constraints you specify.

We are able to use existential sorts with capabilities too, like this:

func travel2(to locations: [String], utilizing car: Automobile) 
    for vacation spot in locations 
        car.journey(to: vacation spot)
    

That may look just like the opposite journey() perform, however as this one accepts any sort of Automobile object Swift can not carry out the identical set of optimizations – it has to make use of a course of known as dynamic dispatch, which is much less environment friendly than the static dispatch out there within the generic equal. So, Swift was ready the place each makes use of of protocols seemed very related, and truly the slower, existential model of our perform was simpler to jot down.

To resolve this downside, Swift 5.6 introduces a brand new any key phrase to be used with existential sorts, in order that we’re explicitly acknowledging the affect of existentials in our code. In Swift 5.6 this new conduct is enabled and works, however in future Swift variations failing to make use of it’ll generate warnings, and from Swift 6 onwards the plan is to situation errors – you can be required to mark existential sorts utilizing any.

So, you’d write this:

let vehicle3: any Automobile = Automobile()
vehicle3.journey(to: "Glasgow")

func travel3(to locations: [String], utilizing car: any Automobile) 
    for vacation spot in locations 
        car.journey(to: vacation spot)
    

I do know it took numerous clarification to achieve this conclusion, however hopefully it is sensible: after we use Automobile as a conformance or a generic constraint we’ll keep it up writing Automobile, however after we use it as its personal sort we should always begin transferring throughout to any Automobile.

It is a large breaking change in Swift. Luckily, like I stated the Swift staff are taking it gradual – right here’s what they stated within the acceptance decision:

“The purpose is that that one can write code that compiles with out warnings for the present Swift launch and a minimum of one main launch prior, after which warnings will be launched to information customers to the brand new syntax in current language modes. Lastly, the previous syntax will be eliminated or repurposed solely in a brand new main language model.”

Kind placeholders

SE-0315 introduces the idea of sort placeholders, which permit us to explicitly specify just some elements of a worth’s sort in order that the rest will be crammed in utilizing sort inference.

In follow, this implies writing _ as your sort in anyplace you need Swift to make use of sort inference, which means that these three strains of code are the identical:

let score1 = 5
let score2: Int = 5
let score3: _ = 5

In these trivial examples sort placeholders don’t add something, however they are helpful when the compiler is ready to appropriately infer a part of a sort however not all. For instance, if you happen to have been making a dictionary of pupil names and all of the examination outcomes they’d this yr, you would possibly write this:

var results1 = [
    "Cynthia": [],
    "Jenny": [],
    "Trixie": [],
]

Swift will infer that to be a dictionary with strings as keys, and an array of Any as values – nearly definitely not what you need. You could possibly specify your entire sort explicitly, like this:

var results2: [String: [Int]] = [
    "Cynthia": [],
    "Jenny": [],
    "Trixie": [],
]

Nevertheless, sort placeholders mean you can write _ instead of the elements you need the compiler to deduce – it’s a approach for us to explicitly say “this half ought to use sort inference”, alongside locations the place we would like an actual sort of our selecting.

So, we may additionally write this:

var results3: [_: [Int]] = [
    "Cynthia": [],
    "Jenny": [],
    "Trixie": [],
]

As you may see, the _ there’s an specific request for sort inference, however we nonetheless have the chance to specify the precise array sort.

Tip: Kind placeholders will be non-compulsory too – use _? to have Swift infer your sort as non-compulsory.

Sorts placeholders do not have an effect on the best way we write perform signatures: you should nonetheless present their parameter and return sorts in full. Nevertheless, I’ve discovered that sort placeholders do nonetheless serve a function for whenever you’re busy experimenting with a prototype: telling the compiler you need it to deduce some sort typically prompts Xcode to supply a Repair-it to finish the code for you.

For instance, you would possibly write code to create a participant like this:

struct Participant<T: Numeric> 
    var title: String
    var rating: T


func createPlayer() -> _ 
    Participant(title: "Nameless", rating: 0)

That fails to specify a return sort for createPlayer(), which is able to trigger a compiler error. Nevertheless, as we’ve requested Swift to deduce the kind, the error in Xcode will supply a Repair-it to switch _ with Participant<Int> – you may think about that saving a good quantity of problem when coping with extra complicated sorts.

Consider sort placeholders as a approach of simplifying lengthy sort annotations: you may exchange all of the much less related or boilerplate elements with underscores, leaving the vital elements spelled out to assist make your code extra readable.

Enable coding of non String/Int keyed Dictionary right into a KeyedContainer

SE-0320 introduces a brand new CodingKeyRepresentable protocol that enables dictionaries with keys that aren’t a plain String or Int to be encoded as keyed containers relatively than unkeyed containers.

To grasp why that is vital, you first have to see the conduct with out CodingKeyRepresentable in place. For instance, this previous code makes use of enum circumstances for keys in a dictionary, then encodes it to JSON and prints out the ensuing string:

import Basis

enum OldSettings: String, Codable 
    case title
    case twitter


let oldDict: [OldSettings: String] = [.name: "Paul", .twitter: "@twostraws"]
let oldData = attempt JSONEncoder().encode(oldDict)
print(String(decoding: oldData, as: UTF8.self))

Though the enum has a String uncooked worth, as a result of the dictionary keys aren’t String or Int the ensuing string shall be [“twitter”,”@twostraws”,”name”,”Paul”] – 4 separate string values, relatively than one thing that’s clearly key/worth pairs. Swift is wise sufficient to acknowledge this in decoding, and can match alternating strings inside every pair to the unique enum keys and string values, however this isn’t useful if you wish to ship the JSON to a server.

The brand new CodingKeyRepresentable resolves this, permitting the brand new dictionary keys to be written appropriately. Nevertheless, as this modifications the best way your Codable JSON is written, you should explicitly add CodingKeyRepresentable conformance to get the brand new conduct, like this:

enum NewSettings: String, Codable, CodingKeyRepresentable 
    case title
    case twitter


let newDict: [NewSettings: String] = [.name: "Paul", .twitter: "@twostraws"]
let newData = attempt! JSONEncoder().encode(newDict)
print(String(decoding: newData, as: UTF8.self))

That can print “twitter”:”@twostraws”,”title”:”Paul”, which is far more helpful exterior of Swift.

For those who’re utilizing customized structs as your keys, it’s also possible to conform to CodingKeyRepresentable and supply your individual strategies for changing your information right into a string.

Unavailability situation

SE-0290 introduces an inverted type of #out there known as #unavailable, which is able to run some code if an availability verify fails.

That is going to be notably helpful in locations the place you have been beforehand utilizing #out there with an empty true block since you solely wished to run code if a selected working system was unavailable. So, relatively than writing code like this:

if #out there(iOS 15, *)   else 
    // Code to make iOS 14 and earlier work appropriately

We are able to now write this:

if #unavailable(iOS 15) 
    // Code to make iOS 14 and earlier work appropriately

This downside wasn’t simply theoretical – utilizing an empty #out there block was a fairly common workaround, notably within the transition to the scene-based UIKit APIs in iOS 13.

Aside from their flipped conduct, one key distinction between #out there and #unavailable is the platform wildcard, *. That is required with #out there to permit for potential future platforms, which meant that writing if #out there(iOS 15, *) would mark some code as being out there on iOS variations 15 or later, or all different platforms – macOS, tvOS, watchOS, and any future unknown platforms.

With #unavailable, this conduct not is sensible: would writing if #unavailable(iOS 15, *) imply “the next code ought to be run on iOS 14 and earlier,” or ought to it additionally embrace macOS, tvOS, watchOS, Linux, and extra, the place iOS 15 can be unavailable? To keep away from this ambiguity, the platform wildcard is not allowed with #unavailable: solely platforms you particularly listing are thought-about for the take a look at.

Extra concurrency modifications

Swift 5.5 added numerous options round concurrency, and 5.6 continues the method of refining these options to make them safer and extra constant, whereas additionally working in the direction of larger, breaking modifications coming in Swift 6.

The most important change is SE-0337, which goals to offer a roadmap in the direction of full, strict concurrency checking for our code. That is designed to be incremental: you may import complete modules utilizing @preconcurrency to inform Swift the module was created with out trendy concurrency in thoughts; or you may mark particular person lessons, structs, properties, strategies and extra as @preconcurrency to be extra selective.

Within the brief time period this makes it considerably simpler emigrate bigger initiatives to trendy concurrency, though @Sendable stays one of the more tricky areas of Swift.

One other space that’s altering is using actors, as a result of on account of SE-0327 Swift 5.6 now points a warning if you happen to try to instantiate a @MainActor property utilizing @StateObject like this:

import SwiftUI

@MainActor class Settings: ObservableObject  

struct OldContentView: View 
    @StateObject non-public var settings = Settings()

    var physique: some View 
        Textual content("Hey, world!")
    

This warning shall be upgraded to an error in Swift 6, so you ought to be ready to maneuver away from this code and use this as an alternative:

struct NewContentView: View 
    @StateObject non-public var settings: Settings

    init() 
        _settings = StateObject(wrappedValue: Settings())
    

    var physique: some View 
        Textual content("Hey, world!")
    

Utilizing @MainActor with @StateObject was particularly recommended at WWDC21, so it’s disappointing to see that the one right code now could be utilizing an initializer that Apple’s personal documentation says to keep away from.

Provided that extra concurrency modifications are clearly en route earlier than Swift 6, I hope this all will get cleaned up in a approach that feels much less like we’re swimming towards the present.

Plugins for Swift Package deal Supervisor

Swift 5.6 features a raft ([1], [2], [3], [4]) of enhancements to Swift Package deal Supervisor, which mix so as to add the beginnings of plugin help utilizing exterior construct instruments.

At this level earlier adopters are reporting that the performance isn’t fairly far alongside sufficient to help extra complex use cases, nevertheless it does a minimum of appear to help SwiftGen and there are additional examples demonstrating potentialities for DocC and swift-format.

This positively seems like an space that may develop in a short time in future releases.

One step nearer to Swift 6

Though we nonetheless haven’t the primary clue when Swift 6 will land (WWDC23, anybody?) it does more and more appear to be Apple’s large likelihood to interrupt numerous issues on the identical time – the prospect to return and clear up issues that weren’t fairly totally baked in time for Swift 3, or weren’t even potential till the foremost modifications launched in 5.1 and 5.5.

So, be in little doubt: Swift 6 could be very prone to break your code. That’s not a dangerous factor, and definitely Apple’s gradual and regular migration path will make the method considerably simpler than the transfer to Swift 3. Nevertheless, it does imply we’re in all probability confronted with one other few years of many tutorials being outdated, finest follow nonetheless being up within the air, and some extent of code churn.

What’s your favourite function of Swift 5.6? Let me know on Twitter!

Sponsor Hacking with Swift and reach the world’s largest Swift community!