What’s new in Swift 6.1? – Donny Wals

Swift 6.1 and TaskGroup

There have been a few adjustments to concurrency in Swift 6.1. These have been primarily small bug fixes and enhancements however one enchancment stood out to me and that’s the adjustments which might be made to TaskGroup. In the event you’re not accustomed to process teams, go forward and skim up on them on my weblog put up proper right here.

Usually, a TaskGroup is created as proven beneath the place we create a process group and specify the kind of worth that each youngster process goes to provide:

await withTaskGroup(of: Int.self) { group in
  for _ in 1...10 {
    group.addTask {
      return Int.random(in: 1...10)
    }
  }
}

Beginning in Swift 6.1, Apple has made it in order that we not need to explicitly outline the return kind for our youngster duties. As an alternative, Swift can infer the return kind of kid duties based mostly on the primary process that we add to the group.

That signifies that the compiler will useaddGroup it finds to find out the return kind for all of your youngster duties.

In follow, that signifies that the code beneath is the equal of what we noticed earlier:

await withTaskGroup { group in
  for _ in 1...10 {
    group.addTask {
      return Int.random(in: 1...10)
    }
  }
}

Now, as you would possibly count on, this does not change the truth that our process teams need to return the identical kind for each youngster process.

The code above exhibits you the way you should utilize this new return kind inference in Swift 6.1. In the event you by accident do find yourself with totally different return sorts on your youngster process just like the code beneath exhibits, the compiler will current us with an error that may let you know that the return kind of your name to addTask is wrong.

await withTaskGroup { group in
  for _ in 1...10 {
    group.addTask {
      return Int.random(in: 1...10)
    }
  }

  group.addTask {
    // Can't convert worth of kind 'String' to closure end result kind 'Int'
    return "Whats up, world"
  }
}

Now, should you discover that you simply do need to have a number of return sorts, I’ve a weblog put up on that. That method nonetheless works. We are able to nonetheless use an enum as a return kind for our process group for our youngster duties, and that undoubtedly nonetheless is a legitimate option to have a number of return sorts in a process group.

I’m fairly proud of this transformation as a result of having to specify the return kind for my youngster duties all the time felt just a little tedious so it’s nice to see the compiler take this job in Swift 6.1.

Subsequent, let’s check out the adjustments to imported member visibility in Swift 6.1.

Imported member visibility in Swift 6.1

In Swift, we’ve got the power so as to add extensions to sorts to boost or increase performance that we have already got. For instance, you might add an extension to an Int to signify it as a forex string or one thing comparable.

If I am constructing an app the place I am coping with currencies and purchases and dealing with cash, I may need two packages which might be imported by my app. Each packages could possibly be coping with currencies ultimately form or kind and I may need an extension on Int that returns a String which is a forex string as I discussed earlier.

This is what that would appear like.

// CurrencyKit
func worth() -> String {
    let formatter = NumberFormatter()
    formatter.numberStyle = .forex
    formatter.locale = Locale.present

    let quantity = Double(self) / 100.0 // Assuming the integer represents cents
    return formatter.string(from: NSNumber(worth: quantity)) ?? "$(quantity)"
}

// PurchaseParser
func worth() -> String {
    let formatter = NumberFormatter()
    formatter.numberStyle = .forex
    formatter.locale = Locale.present

    let quantity = Double(self) / 100.0 // Assuming the integer represents cents
    return formatter.string(from: NSNumber(worth: quantity)) ?? "$(quantity)"
}

The extension proven above exists in each of my packages, and the return kinds of these extensions are the very same (i.e., strings). Which means that I can have the next two information in my app, and it should be simply tremendous.

// FileOne.swift
import PurchaseParser

func dealsWithPurchase() {
    let quantity = 1000
    let purchaseString = quantity.worth()
    print(purchaseString)
}

// FileTwo.swift
import CurrencyKit

func dealsWithCurrency() {
    let quantity = 1000
    let currencyString = quantity.worth()
    print(currencyString)
}

The compiler will know the way to determine which model of worth must be used based mostly on the import in my information and issues will work simply tremendous.

Nonetheless, if I’ve two extensions on integer with the identical operate identify however totally different return sorts, the compiler would possibly truly get confused about which model of the extension I meant to make use of.

Contemplate the next adjustments to PurchaseParser‘s worth technique:

func worth() -> Double {
    let formatter = NumberFormatter()
    formatter.numberStyle = .forex
    formatter.locale = Locale.present

    let quantity = Double(self) / 100.0 // Assuming the integer represents cents
    return quantity
}

Now, worth returns a Double as a substitute of a String. In my app code, I’m able to use this extension from any file, even when that file doesn’t explicitly import PurchaseParser. Because of this, the compiler isn’t certain what I imply once I write the next code in both of the 2 information that you simply noticed earlier:

let quantity = 1000
let currencyString = quantity.worth()

Am I anticipating currencyString to be a String or am I anticipating it to be a Double?

To assist the compiler, I can explicitly kind currencyString as follows:

let quantity = 1000
let currencyString: String = quantity.worth()

This may inform the compiler which model of worth must be used, and my code will work once more. Nonetheless, it’s type of unusual in a manner that the compiler is utilizing an extension on Int that’s outlined in a module that I didn’t even import on this particular file.

In Swift 6.1, we will decide into a brand new member visibility mode. This member visibility mode goes to work just a little bit extra such as you would possibly count on.

Once I import a particular module like CurrencyKit, I am solely going to be utilizing extensions that have been outlined on CurrencyKit. Which means that in a file that solely imports CurrencyKit I gained’t be capable of use extensions outlined in different packages until I additionally import these. Because of this, the compiler gained’t be confused about having a number of extensions with the tactic identify anymore since it might’t see what I don’t import.

Opting into this characteristic could be carried out by passing the corresponding characteristic flag to your package deal, this is what that appears like while you’re in a Swift package deal:

.executableTarget(
    identify: "AppTarget",
    dependencies: [
        "CurrencyKit",
        "PurchaseParser"
    ],
    swiftSettings: [
        .enableExperimentalFeature("MemberImportVisibility")
    ]
),

In Xcode this may be carried out by passing the characteristic to the “Different Swift Flags” setting in your venture settings. In this put up I clarify precisely how to do this.

Whereas I completely love this characteristic, and I believe it is a actually good change in Swift, it doesn’t resolve an issue that I’ve had steadily. Nonetheless, I can undoubtedly think about myself having that drawback, so I am glad that there is now a repair for that that we will decide into. Hopefully, this can finally develop into a default in Swift.

In Abstract

Total, Swift 6.1 is a fairly light-weight launch, and it has some good enhancements that I believe actually assist the language be higher than it was earlier than.

What are your ideas on these adjustments in Swift 6.1, and do you suppose that they may impression your work in any manner in any respect?