Issues — EvolutionKit Your guide to Swift Evolution — tracking proposals, changes, and what's coming next in the Swift language. https://evolutionkit.dev/blog/ en Swift Evolution Monthly: May-November 2024 https://evolutionkit.dev/blog/swift-evolution-monthly-may-november-2024/ https://evolutionkit.dev/blog/swift-evolution-monthly-may-november-2024/ Thu, 21 Nov 2024 00:00:00 +0000 Swift Evolution Monthly: May-November 2024

Swift’s GitHub repositories have officially moved from the Apple organization to the new swiftlang organization during the summer, signaling a significant step in Swift’s evolution as a community-driven language. Meanwhile, Swift 6 brought major advances in concurrency and data-race safety. But since those changes are already well-documented in other places, I will skip the concurrency topic and focus on other improvements to Swift that are around the corner.

Looking ahead, Swift’s evolution isn’t just about concurrency. Ongoing efforts, such as the proposed Vision document for Strictly-Safe Swift, are expanding the language’s capabilities beyond app development, particularly in embedded systems or system-level programming. That said, this newsletter remains grounded in what matters most to app developers. So let’s dive in!

Accepted Proposal Summaries

SE-0436: Objective-C implementations in Swift

Links: 📝 Proposal | 💬 Review | ✅ Acceptance

A new syntax allows implementing Objective-C headers in Swift while maintaining full backward compatibility. This is particularly valuable when modernizing existing iOS apps with Swift while keeping Objective-C compatibility:

// MyView.h
@interface MyView : UIView
@property (nonatomic) CGFloat cornerRadius;
- (void)animate;
@end
// MyView.swift
@objc @implementation extension MyView {
    var cornerRadius: CGFloat = 0 {
        didSet { layer.cornerRadius = cornerRadius }
    }

    func animate() {
        // Swift implementation that's fully compatible with Objective-C
    }
}

This bridges the gap between modern Swift development and legacy Objective-C code, making gradual migration easier. While most relevant for teams maintaining Objective-C codebases, it’s useful for any iOS developer working with mixed codebases or third-party Objective-C frameworks. And certainly Apple system engineers modernizing old system frameworks using Swift.

SE-0438: Metatype Keypaths

Links: 📝 Proposal | 💬 Review | ✅ Acceptance

This proposal allows keypath expressions to access static properties in Swift, introducing metatype keypaths using the .Type syntax.

Here’s a practical example of how it simplifies code, especially when working with databases or property wrappers:

struct User {
    static let tableName = "users"
    static let primaryKey = "id"
}

// Before: Required workarounds or verbose syntax
let table = database.table(named: User.tableName)

// After: Can use keypaths directly
let tableKeyPath = \User.Type.tableName
let table = database[keyPath: tableKeyPath]

This is a moderate improvement that will be particularly valuable for developers working with frameworks that use keypaths extensively (like SwiftData or other database layers) and those building property wrapper-based systems. While not revolutionary, it removes an annoying limitation that required developers to create workarounds for accessing static properties through keypaths.

Now, we’re just missing Enum Case Keypaths – I hope we get them soon!

SE-0439: Allow trailing comma in comma-separated lists

Links: 📝 Proposal | 💬 Review | ✅ Acceptance

This proposal extends Swift’s existing trailing comma support (currently limited to arrays and dictionaries) to all comma-separated lists that have clear terminators, like function parameters and tuples.

Here’s a practical example showing how it improves code maintenance, especially with version control:

func fetchUser(
    id: String,
    includeDetails: Bool = true,
    cachePolicy: CachePolicy = .default, // Adding/removing params now cleaner
) {
    // ...
}

let coordinates = (
    latitude: 37.7749,
    longitude: -122.4194,
) // Better diffs when modifying values

This is a small but meaningful quality-of-life improvement that will be particularly appreciated by developers working on large codebases where code formatting and version control cleanliness are important. It reduces noise in git diffs and makes code reorganization smoother. Nice to see these kinds of improvements!

SE-0443: Precise Control Flags over Compiler Warnings

Links: 📝 Proposal | 💬 Review | ✅ Acceptance

Swift adds granular control over compiler warnings, allowing developers to selectively upgrade warnings to errors or keep certain warnings as warnings. This is particularly valuable when maintaining large codebases:

// See which group a warning belongs to
swiftc -print-diagnostic-groups MyApp.swift

// Treat all warnings as errors except deprecations
swiftc -warnings-as-errors -Wwarning deprecated MyApp.swift

// Only make API availability warnings into errors
swiftc -Werror availability MyApp.swift

This feature helps teams maintain strict code quality while being pragmatic about certain warning categories. For example, you can enforce strict handling of memory management warnings while allowing time to address deprecation warnings during major version upgrades. It’s especially useful when upgrading to new Swift versions or SDK releases that introduce new deprecations.

SE-0444: Member import visibility

Links: 📝 Proposal | 💬 Review | ✅ Acceptance

Did you ever notice that you could access extensions from third-party Swift packages you didn’t even import in a given Swift file? While you always needed to import a module to use its types, extensions on existing types like String were silently available through transitive imports. Here’s why that’s problematic:

// Without importing GroceryKit, its extensions are still available
import RecipeKit
let recipe = "ingredients...".parse() // Ambiguous if GroceryKit adds parse()!

// The fix: Extensions need explicit imports
import RecipeKit
let recipe = "ingredients...".parse() // Unambiguous - only sees RecipeKit's parse()

This proposal fixes this inconsistency in Swift’s module system by making extension methods follow the same visibility rules as types. Due to the breaking change nature (you may need a lot more imports), it will initially be available behind the MemberImportVisibility compiler flag before becoming the default behavior in a future Swift version.

SE-0445: Improving String.Index’s printed descriptions

Links: 📝 Proposal | 💬 Review | ✅ Acceptance

A quality-of-life improvement coming in Swift 6.1 that makes debugging string operations easier by giving String.Index values more meaningful descriptions:

let text = "👋🏼 Hello"

// Before: Cryptic output
print(text.firstRange(of: "el")!)
// Index(_rawBits: 655623)..<Index(_rawBits: 852487)

// After: Clear position information
print(text.firstRange(of: "el")!)
// 6[utf8]..<8[utf8]

This is a small but useful enhancement that will particularly benefit developers working on text processing code or debugging string-related issues.

Other Accepted Proposals

✉️ Don’t want to miss future issues? Subscribe to the newsletter.

Proposals in Progress

Noteworthy Active Threads

Other News

Before wrapping up, I want to highlight Proposal Monitor by Victor Martins—a perfect companion for anyone wanting to dive deeper into Swift Evolution. While this newsletter keeps you informed about key developments, Proposal Monitor is ideal if you want to track every proposal, stay up-to-date with push notifications, or give timely feedback during review periods. Available on iOS, iPadOS, and visionOS, it’s a fantastic tool for following Swift’s evolution more closely.

]]> Swift Evolution Monthly: February-April 2024 https://evolutionkit.dev/blog/swift-evolution-monthly-february-april-2024/ https://evolutionkit.dev/blog/swift-evolution-monthly-february-april-2024/ Sat, 04 May 2024 00:00:00 +0000 Swift Evolution Monthly: February-April 2024

WWDC24 is just a month away and there are 2 ways I’ll be involved: Firstly, I’ll be in the area for the whole week and join all community events I can! Paul Hudsons great video about his experience in 2023 convinced me that it’s worth it even if you didn’t get the golden ticket for Apple Park. Maybe we’ll meet there?

Secondly, I’m working on a complete overhaul of the WWDC Notes community project that I took over last year. If you don’t know, it’s a place where members of our community share their WWDC session notes for other members in the community. This work is needed because only the notes are public, most of the projects repos (website, etc.) are not. Writing the notes is also annoying, because the website renderer doesn’t support all Markdown features and you have no way to preview them locally. My plan is to fix both issues by migrating the project over to Swift-DocC. This will allow you to preview the rendering right within Xcode!

Speaking of tools I develop for the community, I just shipped a free tool that helps you manage your localizations more efficiently and finds bugs. Give it a try!

Moving on to Swift Evolution News – it’s official now, Swift 6 is coming this year at WWDC! Several of the accepted proposals I link to below have their state marked as “Implemented for Swift 6”. You’ll notice by the proposals currently being worked, that the main focus is ironing out rough edges of Swift Concurrency before the release of Swift 6, which will introduce a couple of extra safety checks.

If the release of a major new Swift version with breaking changes concerns you, Holly Borla from the Swift Core team is here put you at ease. In this post, she makes clear that the Swift 6 compiler will default to a Swift 5 compatibility mode, not breaking any of your code or your packages code. Only if you explicitly opt-in to Swift 6 mode, which you can do module by module, you’ll get the new safety checks, warnings, and errors. This means you can adopt Swift 6 at your own pace!

Accepted Proposal Summaries

SE-0419: Swift Backtrace API

Links: 📝 Proposal | 💬 Review | ✅ Acceptance

On a first look, this proposal reads like one could build a crash reporting tool based on a new SymbolicatedBacktrace struct it introduces. But then it states this:

(…) the API presented here is not async-signal-safe, and it is not an appropriate tool with which to build a general purpose crash reporter. The intended use case for this functionality is the programmatic capture of backtraces during normal execution.

While backtracing and symbolication sound complex, usage can be as simple as:

import Runtime

enum SomeNamespace {
  static func doSomething() {
    do {
      try somethingThatCanFail()
    } catch {
      let bt = Backtrace.capture().symbolicated()
      if let sl = bt.frames[0].symbolInfo?.sourceLocation {
        print("Called from file \(sl.path) at line \(sl.line)")
      }
    }
  }
}

Note that you need to import Runtime to use the new backtracing capabilities. As you can see in the code above, it’s easy to access the file and line of the current execution context. Think of frames like the left sidebar showing the whole call stack when you run into a breakpoint or your app crashes during debugging.

With Swift Backtrace APIs, things like debugging and performance analysis can be hugely improved because they make it much easier to diagnose our code. In complex applications, capturing a backtrace at the point of error or exception can even help us trace issues without halting the application. I can also imagine this to be super helpful for debugging & error handling for Swift on Server.

SE-0421: Generalize effect polymorphism for AsyncSequence and AsyncIteratorProtocol

Links: 📝 Proposal | 💬 Review | ✅ Acceptance

Not being a compiler expert, I don’t fully understand this proposal. It reads similarly abstract like the title makes it sound. But I understand that there were serious problems with AsyncSequence regarding error handling (throws) and Sendable conformance. And this proposal introduces an associated Failure type and adopts my all-time favorite proposal SE-0413 Typed Throws to fix those issues, including for AsyncIteratorProtocol with a next() overload.

I think all us app developers really need to take away from this (and other accepted proposals in the recent past I didn’t cover in detail) is that Apple is really focusing on getting concurrent code in Swift to a much better place with Swift 6. I’m curious to see what new consumer features or developer APIs all this work leads up to. Maybe we’ll know more next month after WWDC24? Let’s see!

SE-0428: Resolve DistributedActor protocols

Links: 📝 Proposal | 💬 Review | ✅ Acceptance

It’s really hard to grasp the future impact of distributed actors in Swift, partly because the topic is inherently complicated, and partly because things are still in the works and practical usage examples are scarce. But certainly this proposal brings us another step closer to a future where if you control your own server, you might be able to get rid of the API layer entirely and just let the distributed actor system figure the communication details out for your client-server application.

Having that said, it’s still not clear if this is the intended use case within Apple. I’m sure there are products or services that will profit from the work in this area, but I still struggle with a clear picture. The only things that come to my mind are uses where (part of) the processing happens on non-integrated parts. Such as the Vision Pro doing part of the processing in the battery pack in a future iteration. Or Siri processing parts of a request in the Cloud. I’m really curious to see what the future brings. I have a feeling that distributed actors might play a big role at some point.

SE-0433: Synchronous Mutual Exclusion Lock

Links: 📝 Proposal | 💬 Review | ✅ Acceptance

When we have shared mutable state in our apps and want to avoid race conditions that could lead to inconsistent state or unexpected results, our go-to solution in Swift should be using Actors. But actors have their own requirements, and sometimes it’s not possible or reasonable to use them. In those cases…

Many Swift programs opt to use ad-hoc implementations of a mutual exclusion lock, or a mutex. (…) The main issue is that there isn’t a single standardized implementation for this synchronization primitive resulting in everyone needing to roll their own.

So this proposal does exactly that, it introduces an “official” Swift Mutex type. You need to import Synchronization to use it. Then, you can write something like:

let imageCache = Mutex<[UUID: Data]>([:])

Now, whenever you want to write to the dictionary, you call .withLock like this:

imageCache.withLock { dict in
  dict[UUID()] = Data()
}

Note that a Mutex cannot be defined as var, only let works for safety reasons. Besides .withLock, there’s also withLockIfAvailable which returns nil if the lock couldn’t be acquired. Please be aware that a Mutex works very differently from an Actor and therefore is prone to classic problems like deadlocks. But if you know what you’re doing and you need a mutex, Swift will have you covered.

Other Accepted Proposals

✉️ Don’t want to miss future issues? Subscribe to the newsletter.

Proposals in Progress

  • SE-0403: Package Manager Mixed Language Target Support 📝 Proposal | 💬 Review | 🔄 Returned

  • SE-0406: Backpressure support for AsyncStream 📝 Proposal | 💬 Review | 🔄 Returned

  • SE-0415: Function Body Macros 📝 Proposal | 💬 Review | 🔄 Returned

  • SE-0423: Dynamic actor isolation enforcement from non-strict-concurrency contexts 📝 Proposal | 💬 Reviews: 1st, 2nd

  • SE-0427: Noncopyable Generics 📝 Proposal | 💬 Review

  • SE-0430: transferring isolation regions of parameter and result values 📝 Proposal | 💬 Review | 🔄 Returned

  • SE-0431: @isolated(any) Function Types 📝 Proposal | 💬 Review

  • SE-0432: Borrowing and consuming pattern matching for noncopyable types 📝 Proposal | 💬 Review

  • SE-0434: Usability of global-actor-isolated types 📝 Proposal | 💬 Review

  • SE-0435: Swift Language Version Per Target 📝 Proposal | 💬 Review

Noteworthy Active Threads

Other News

On the organizational front, the Core Team has announced the formation of a “Platform Steering Group”. According to its page on Swift.org their goals are to “enable the Swift language and its tools to be used in new environments” and to “drive development work that brings the Swift (…) to a variety of platforms”.

And finally, don’t forget to try the 2.0 release of TranslateKit to find common bugs in your localizations. Such as %lld of %lld which should be %1$lld of %2$lld. Or a missing %@ in translations. And many more – all for free!

]]> Swift Evolution Monthly: January '24 https://evolutionkit.dev/blog/swift-evolution-monthly-january-24/ https://evolutionkit.dev/blog/swift-evolution-monthly-january-24/ Fri, 09 Feb 2024 00:00:00 +0000 Swift Evolution Monthly: January '24

Thanks to Antoine’s idea to point to other related newsletters upon subscribing, the number of people receiving this issue more than doubled within the last month, so hello and welcome on board to everyone new! 👋

January was also quite a busy month for me personally. Just as a mini recap, I shipped a huge 2.0 update to my puzzling game CrossCraft and I released a new developer app – TranslateKit – after weeks of frustration due to nonsensical rejections by the Review team. 😩 I’d love you to give both a try! The latter even launched on Product Hunt today. 👀

Note that I migrated CrossCraft to visionOS for day 1 of the Apple Vision Pro and even live-streamed the entire process here. I will upload a shorter video there. Speaking of the Vision Pro, I also released another app which I specifically developed for it to fix a flaw in the visionOS user interface. 🕓🔋

On other news, the swift.org website underwent a redesign. I really like how the crowded sidebar was replaced with a more organized top bar! Good job. 👏

Accepted Proposal Summaries

SE-0410: Low-Level Atomic Operations

Links:📝 Proposal | 💬 Reviews: 1st, 2nd | ✅ Acceptance

This introduces low-level synchronization primitives hidden behind a module named Synchronization that you need to explicitly import to use them. App developers should probably stick to the recently introduced concurrency features like async/await, but for Swift to be successful as a systems programming language, new low-level APIs like the Atomic type introduced here are important. Some libraries also might use it internally.

SE-0416: Subtyping for keypath literals as functions

Links:📝 Proposal | 💬 Review | ✅ Acceptance

This small proposal allows using key paths in some situations that were previously impossible. For example, the compiler is currently not able to convert the Int to an Int? (like it can in other contexts) in following code:

struct Person {
  var age: Int
}

// error: Key path value type 'Int' cannot be converted to contextual type 'Int?'
let x: (Person) -> Int? = \.age

In the future, key paths will work in more situations, including the above.

SE-0417: Task Executor Preference

Links:📝 Proposal | 💬 Review | ✅ Acceptance

This proposal is mostly for improving the performance on event-loop based systems like network servers. It introduces a new flexible mechanism for developers to tune their applications and avoid potentially unnecessary context switching when using Swift concurrency. Read the full proposal if this affects you. Most app developers probably are good with the current defaults.

SE-0418: Inferring Sendable for methods and key path literals

📝 Proposal | 💬 Review | ✅ Acceptance

This one improves flexibility, simplicity, and ergonomics in some edge cases by inferring @Sendable in more situations surrounding functions as values and key path literals. As a quick reminder, the Sendable protocol indicates that a type is safe to be passed to other Tasks and Actors in Swift concurrency. You’ve probably already seen warnings in some places when using async/await. In Swift 6, some (or all?) of those warnings will become compiler errors, so it’s good news that Sendability is inferred in more situations to reduce friction when entering the world of more strict safety.

SE-0420: Inheritance of actor isolation

📝 Proposal | 💬 Review | ✅ Acceptance

Here’s another change that will reduce the friction around Sendable types in Swift 6. The purpose of this proposal is to allow non-Sendable data to be safely passed to functions by inheriting the isolation context. An isolated keyword (introduced in SE-0313) can be put in front of actor types alongside an #isolation expression as a default value to achieve that. As a result, functions might get declared like this:

func foo(isolation: (any Actor)? = #isolation) async

If you want to learn more about the isolated keyword, the same Antoine I mentioned at the beginning has written a great article about it.

All in all, I really like the continued effort in Swift to make concurrency work more smoothly in more situations. I have a feeling that Swift 6 isn’t too far off anymore, given that we are seeing more edge cases being tackled. Maybe later this year? 🤞

✉️ Don’t want to miss future issues? Subscribe to the newsletter for free.

Proposals in Progress

Noteworthy Active Threads

I love how Swift is becoming more widely usable, which I’m sure will make it a better language for app developers, too.

I’m also particularly excited about the first link in the “Active Threads” section. If I understood it correctly on a quick read, it has the potential to make away with the need to write API clients for servers altogether, hiding the client-server communication in a distributed actor. Check it out!

That was it for January. Don’t forget to try CrossCraft & TranslateKit! 🌟🙏

]]> Swift Evolution Monthly: December '23 https://evolutionkit.dev/blog/swift-evolution-monthly-december-23/ https://evolutionkit.dev/blog/swift-evolution-monthly-december-23/ Mon, 25 Dec 2023 00:00:00 +0000 Swift Evolution Monthly: December '23

Back when there was no Swift on Server, I used to develop my backends with Ruby on Rails. And I remember how the Ruby team tried to time their major releases for Christmas which made it feel a bit like a gift from Santa. Now I feel like the Swift team has managed to do the same this year – their gift is the acceptance of Typed Throws into the Swift language! 🎁 Yes, it’s really coming. 😍🎉

But before I get to the proposals, I want to mention 2 things:

You might have noticed that there have been no issues of this newsletter since July. That’s simply because I decided that I would no longer attempt to summarize every single proposal. Instead, I’ll focus on those that are most interesting to app developers like myself. My summaries for the more low-level or the advanced server-only topics weren’t very useful anyway. But I will still link to them for those interested!

Speaking of app development, you could make me a little gift by checking out my newest Indie app creation – it’s an app to craft themed & personalized crossword puzzles. You’re not a fan of crosswords? But you might still be interested in a fun challenge about a topic you like, such as Swift/iOS Development, Technology, or one of the other 20 topics in various categories. Test your knowledge or prepare a special gift for your loved ones. Try it now & rate it to support me. Thanks! 🙏 👇

‎CrossCraft: Custom Crosswords

Creating, playing, and sharing crossword puzzles is free!

Accepted Proposal Summaries

SE-0413: Typed throws

Links:📝 Proposal | 💬 Review | ✅ Acceptance

This is probably the most requested Swift feature in recent years. Many have asked for it, but some rejected it, too. Here’s what it’s all about:

Imagine you use a function you didn’t write yourself (or wrote years ago) that is throwing, such as func parseCSVFile(at url: URL) throw -> [Entry]. Let’s say the function throws in 3 different cases:

  1. When no file exists at the given path

  2. When the app has no access to the path (Sandbox)

  3. When the contents of the file have an invalid format

Unless those 3 cases are documented on the function (which even Apple doesn’t do on most system APIs), you can’t easily know or handle them separately for a custom-tailored experience. You’d have to read through the full implementation of the function and all throwing functions the function calls inside. A time-consuming and error-prone task. Sometimes you don’t even have access to the implementation.

For example, if no file exists at the provided path, you might want to traverse all files in the folder and see if you can find a similarly named file, e.g. using a Levenshtein distance of 2 or lower. If you find a similar one, you could ask the user if they meant that file instead. Depending on your use case, this might be a welcome improvement over just showing a generic error message, which just delegates error handling to the user.

With typed throws in Swift, the author of the parseCSVFile function will have the option to explicitly specify the possible throwing cases. Typically, an enum type is created to represent the possible cases like so:

enum CSVParsingError: Error {
   case noFileFound(url: URL)
   case noAccessToPath(url: URL)
   case invalidContentFormat(line: Int?)
}

These types often exist already for many throwing functions. However, the function declaration doesn’t contain information about the type yet. Now it can:

func parseCSVFile(at url: URL) throws(CSVParsingError) -> [Entry]

The only option API authors had until now to make the error type explicit was to return Result<[Entry], CSVParsingError> instead, which will no longer be needed. To handle each error case separately, you can then switch-case over the possible errors in the catch block like so:

do {
   let entries = try parseCSVFile(at: userProvidedURL)
   // ...
} catch {
   switch error {
   case .noFileFound: // try to find similarly named ones
   case .noAccessToPath: // show UI to fix Sandbox access
   case .invalidContentFormat: // ask user: skip line or cancel
   }
}

The error in the catch block is of type CSVParsingError, not any Error!

This is a huge improvement, as you know exactly what can fail and can react to each case differently, as I hinted at in the comments. Not only that, you also don’t have a default case, so if you wanted to handle each error with a special UI, you can. No need for a generic text message UI at all, which you always would have needed with untyped errors, cause there could always be an error you missed or that gets added later on. With typed throws, the compiler ensures you handle all cases and fails at compile-time if you don’t, even if new cases got added to the function.

Does that mean we can expect all future Apple system APIs to have a documented error type, exposing all possible error cases? No, unfortunately not. This has technical reasons: Apple ships new versions of their operating systems regularly, changing APIs all the time. Users expect apps to run on newer OS versions without the need for us to resubmit our apps. If Apple added a new error case to the above enum, like providedPathIsAFolder all apps that use a switch-case would have undefined behavior if that new error occurred. Therefore only those few functions where the error cases are clear forever by the functions nature can adopt typed throws on the system level. Those are probably rare.

But 3rd-party developers are much more flexible as their frameworks are updated and recompiled by the app developer in Xcode, not by the user via a system update. If they specify the error type explicitly, they simply make the errors part of their public API, therefore changes to the errors would break the API. With proper versioning, this is not a problem – which doesn’t mean that all functions should adopt typed throws. Some probably still shouldn’t. But they have a choice now. And app developers should be able to use typed throws for their project-internal functions without issues.

To not specify an error type, continue to specify your functions as throws without a type, in which case the old any Error behavior remains – a throws effectively is equal to throws(any Error). This also means that the change is fully source-compatible and people can adopt typed throws step by step.

There are a lot more details in the proposal about things like subtyping, its relation with the Result type or rethrows, and much more. Read it to learn more!

SE-0404: Nested Protocols in Non-Generic Contexts

Links:📝 Proposal | 💬 Review | ✅ Acceptance

If you have ever defined a protocol type that is closely related to another type, you might have wanted to define the protocol directly inside the type. This has two advantages: It namespaces it to make the connection clear, and when using it inside the type, its name is much shorter and to the point. But protocols had to be defined globally until now. Not anymore – in the future they can be placed in non-generic contexts like classes, structs, or enums. For example, this allows Apple to move protocols like UITableViewDelegate into related namespaces as follows:

extension UITableView {
   protocol Delegate {
      // ...
   }
}

To reference the protocol, you would write UITableView.Delegate.

To keep existing code compatible with the rename, they could define a typealias:

typealias UITableViewDelegate = UITableView.Delegate

And of course, we all can use this, too! The future of Swift is going to be more namespaced, which I think can make code more readable overall. 👍

SE-0409: Access-level modifiers on import declarations

📝 Proposal | 💬 Review | ✅ Acceptance

This one is only important to library authors or those who modularize their apps using SwiftPM. It adds the private, internal, and public keywords to import statements. If you private import a dependency, it’s only usable in private or fileprivate declarations in the current file. If you internal import a dependency, you can additionally use the dependency on internal signatures. Only if you public import a dependency, you can use it additionally on public or open declarations, which is equal to the current behavior of a simple import.

The purpose of this proposal is to give package authors the possibility to hide implementation details. Because if there’s no public import of a given dependency B in your whole package, the compiler no longer has to make that dependency B available to users of your package A and can strip it. This will help limit dependency creep and will make our package ecosystem healthier as a whole.

Note that with Swift 5, if you don’t specify the access level and use a simple import, it will effectively be treated as a public import. But starting with Swift 6 this behavior will change, it will be treated as an internal import instead and no longer be usable in public declarations. Migration will be easy though, just add public where you get a compilation error. Xcode might even provide a fix-it. 🤞

✉️ Don’t want to miss future issues? Subscribe to the newsletter for free.

Other Accepted Proposals

- SE-0411: Isolated default value expressions 📝 [Proposal](https://github.com/apple/swift-evolution/blob/main/proposals/0411-isolated-default-values.md) | 💬 [Review](https://forums.swift.org/t/se-0411/68065) | ✅ [Acceptance](https://forums.swift.org/t/accepted-se-0411-isolated-default-value-expressions/68806) - SE-0412: Strict concurrency for global variables 📝 [Proposal](https://github.com/apple/swift-evolution/blob/main/proposals/0412-strict-concurrency-for-global-variables.md) | 💬 [Review](https://forums.swift.org/t/se-0412-strict-concurrency-for-global-variables/68352) | ✅ [Acceptance](https://forums.swift.org/t/accepted-se-0412-strict-concurrency-for-global-variables/69004)

Proposals in Progress

Noteworthy Active Threads

And that’s it for December. Don’t forget to try my new app CrossCraft. 🧩
And happy holidays, everyone 🎄 ☃️ 🎆

]]> Swift Evolution Monthly: June '23 https://evolutionkit.dev/blog/swift-evolution-monthly-june-23/ https://evolutionkit.dev/blog/swift-evolution-monthly-june-23/ Mon, 03 Jul 2023 00:00:00 +0000 Swift Evolution Monthly: June '23

WWDC23 was full of hardware announcements and even brought us a new platform: visionOS. Xcode 15 and Swift 5.9 are also in beta phase now with a great set of new features. Of course, for readers of this newsletter, there were no big surprises in the “What’s New in Swift” session (except for the large focus on C++ interoperability). But if you didn’t have the time to check out the other sessions, including those about Swift Macros which were a focus in the last 3 issues, you might want to visit the WWDC Notes project website which has a dedicated section with notes about this year’s sessions. At the time of this writing, 75 sessions from 2023 were already covered by 25+ amazing community members, and still counting. 🎉🙏

If you don’t know where to start, I’ve prepared a thread with a ~250-character-long summary twoot for each of my personal Top 25 sessions. It can both help you learn some tidbits of these sessions with minimal time & explore the ones you might want to dive into further by reading the full notes or watching the session:

🐦 Twitter Thread | 🐘 Mastodon Thread

Accepted Proposals

No new proposals were accepted in June. 😱 I guess that’s a consequence of 7 proposals being accepted in May to make it into the language before WWDC.

I’m also skipping the old proposal, no one seems to be using the repo anyway. 🤷‍♂️

But there are two new proposals in Review, so after the packed May issue and a light June issue this time, we might get a decent July issue next month. 🤞

Worth noting that a milestone of 400 proposals has been reached! 💯💯💯💯 🥳

Proposals in Progress

✨ Want to see your ad here? Contact me at ads@fline.dev to get in touch.

Recently Active Pitches/Discussions

Other Developments Worth Mentioning

A really cool open-source surprise at WWDC was the Swift OpenAPI Generator announcement. Apple dedicated a full session to it and I recommend watching it if you happen to have an app with its own server, or if you plan to add a server to your app in the future. The most amazing thing about this new set of libraries is how flexibly you can make use of them:

You were using a networking library in your app or you wrote your own networking client using URLSession? No more: Just generate the client code.

You were using Vapor as a server and had to map your routes and parameters to your business logic manually? No more: Just generate the server code.

You were using complex workflows to ensure your non-Swift server and your Swift client are always in sync? No more: Just write a YAML file like any other code.

OpenAPI (not to mix up with OpenAI) is an industry-standard for HTTP API specs and there’s a ton of tooling around the API spec that can help streamline API creation, documentation, testing, and usage – Apple’s tools are just the latest to join a big family. At the core of OpenAPI is the spec file – I recommend writing one with a GUI like APIGit so you don’t have to remember the syntax – this was the only one I found to support typed params and having a useful Free tier.

There’s also a process to influence the future direction of the project in a very similar (but more lightweight) manner to Swift Evolution itself, learn more here.

And that’s it for June! It’s been a busy month but it was fun. 🍏🥽

💁🏻‍♂️ Enjoyed this article? Check out TranslateKit! A drag & drop translator for String Catalog files – it’s really easy. Get it now to machine-translate your app to up to 150 languages!

]]> Swift Evolution Monthly: May '23 https://evolutionkit.dev/blog/swift-evolution-monthly-may-23/ https://evolutionkit.dev/blog/swift-evolution-monthly-may-23/ Sun, 04 Jun 2023 00:00:00 +0000 Swift Evolution Monthly: May '23

WWDC is rapidly approaching – and if last year is any sign, then many of the proposals covered in past issues and down below in this one will be an integral part of the session videos: Either because Apple introduces new APIs only possible thanks to recent changes in Swift, or simply to give developers advice on how to make use of Swifts latest features. As many things are going on in the community right now inspired by WWDC, I will try to keep this issue as short as possible.

I don’t want to skip these two topics though:

  1. The WWDC Notes project is more active than ever this year. With the help of the community, we aim to cover 80% of all sessions within the first week. Over 20 volunteers joined within a few days, and we are looking for more contributors. If you’re unable to watch many sessions, you can still help (and profit) by contributing notes for one or two sessions. Together, we can achieve a lot. Join us on Slack & send me the topics you’re interested in to get involved!

  2. To celebrate WWDC within my own work, I decided to add some useful and completely free features to my developer-focused app RemafoX. Also, there’s a massive sale during WWDC for those interested in its advanced features. I’ll leave you with a GIF demoing the new free features:

Note that noncopyable structs can have a deinit method, which normal structs can’t have.

Accepted Proposals

7 new proposals were accepted in May, so I’m skipping on the old one this time.

SE-0386: New access modifier: package

Links:📝 Proposal | 💬 Reviews: 1st, 2nd | ✅ Acceptance

Currently, Swift library authors that like to split their code into separate modules have to use the public access modifier to make any APIs available from one (helper) module to another. This makes these APIs available to all users of the package, even if the API is not intended for public use. Library authors have to stick to a single module design to actually keep helper functions internal to the package.

Not anymore! The new access modifier package can be used in the future to mark any API as “internal to the package”, making it available to other modules within the same package, but not accessible to users of the package. 🎉

SE-0390: Noncopyable structs and enums

Links:📝 Proposal | 💬 Reviews: 1st, 2nd | ✅ Acceptance

In Swift, we currently have value types (like struct) and reference types (like class). We use value types to represent blobs of data that are implicitly copied when we pass them along to other functions. We use reference types whenever we don’t want this copying behavior and instead want to pass a pointer so there’s a single object that can be changed by other functions directly.

This proposal introduces a third concept that can be often used in place of a class in the future: A “noncopyable” type. You can create a struct and conform it to ~Copyable (read: “suppress Copyable”) and when passing it along to functions, it won’t be copied implicitly. But unlike classes, there’s no overhead of storing the data in the heap (saves memory) or reference counting (saves CPU cycles).

The example provided in the proposal is a FileDescriptor:

struct FileDescriptor: ~Copyable {
  private var fd: Int32

  init(fd: Int32) { self.fd = fd }

  func write(buffer: Data) {
    buffer.withUnsafeBytes { 
      write(fd, $0.baseAddress!, $0.count)
    }
  }

  deinit {
    close(fd)
  }
}

Note that noncopyable structs can have a deinit method, which normal structs can’t have.

There are some requirements for nested types (they need to be ~Copyable, too) and limitations for generic types (see workarounds). But this sounds like it’s going to change some current Best Practices about correct and performant Swift code. Read this section to learn more about the usage of noncopyable types.

SE-0392: Custom Actor Executors

Links:📝 Proposal | 💬 Reviews: 1st, 2nd | ✅ Acceptance

This proposal introduces the concept of custom executors and customization points in Swift Concurrency, providing developers with greater control over the execution semantics of their actors. I’m not in a position to customize executors, so I can’t provide practical implications. But the motivation section ends with this:

Along with introducing ways to customize where code executes, this proposal also introduces ways to assert and assume the appropriate executor is used. This allows for more confidence when migrating away from other concurrency models to Swift Concurrency.

SE-0396: Conform Never to Codable

Links:📝 Proposal | 💬 Review | ✅ Acceptance

This is probably the shortest proposal I’ve ever summarized, so let’s keep it short: The proposal suggests adding Codable conformance to the Never type in Swift. This allows encoding but throws an error for decoding attempts, addressing a limitation with generic types that involve Never, like Either<Int, Never>.

✨ Want to see your ad here? Contact me at ads@fline.dev to get in touch.

SE-0397: Freestanding Declaration Macros

Links:📝 Proposal | 💬 Reviews: 1st, 2nd | ✅ Acceptance | 🔮 Vision

The proposal extends Swift’s macros to allow generating declarations, enabling use cases like generating data structures from templates or introducing warning/error directives as macros. It introduces freestanding declaration macros that use the # syntax and have type-checked arguments, producing zero or more declarations. For example, the #warning directive from SE-0196 can be declared as a freestanding declaration macro like so:

@freestanding(declaration) 
macro warning(_ message: String) = #externalMacro(module: "MyMacros", type: "WarningMacro")

The implementation part is a bit more involved like with any other macros though.

SE-0398: Allow Generic Types to Abstract Over Packs

Links:📝 Proposal | 💬 Review | ✅ Acceptance

This introduces the ability to use generic types to abstract over packs of types. It generalizes the concepts introduced in SE-0393, which allowed generic function declarations to abstract over a variable number of types (each T). With this proposal, you can define generic type declarations that abstract over multiple types, enabling the creation of more flexible and generalized algorithms.

This allows defining functions like zip where the return type needs an arbitrary number of type parameters – one for each input sequence:

func zip<each S>(_ seq: repeat each S) -> ZipSequence<repeat each S>
  where repeat each S: Sequence

The return type ZipSequence<repeat each S> is what this proposal allows.

SE-0399: Tuple of value pack expansion

Links:📝 Proposal | 💬 Review | ✅ Acceptance

Also building upon SE-0393, this one enables referencing a tuple value that contains a value pack inside a pack repetition pattern. Currently, there is no way to reference individual elements of a value pack within a tuple or pass them as arguments to a function. This proposal fills that gap by allowing pack repetition patterns to operate on tuple values containing value packs, providing a method to access individual value pack elements within a tuple. For example:

func tuplify<each T>(_ value: repeat each T) -> (repeat each T) {
  return (repeat each value)
}

func example<each T>(_ value: repeat each T) {
  let abstractTuple = tuplify(repeat each value)
  repeat print(each abstractTuple) // okay as of this proposal
}

Proposals in Progress

Recently Active Pitches/Discussions

Other Developments Worth Mentioning

If you want to enable Swift 6 features today, James Dempsey wrote a detailed article on the Swift blog just a few days ago on how to do that. I had already enabled “Swift 6” mode in April in my apps and documented my experience here.

Lastly, the Swift Core Team announced changes to how workgroups are named and operate in this blog post. Basically, there will be two tiers of groups: steering groups, responsible for overall strategic direction, and workgroups, focused on specific areas of the project. The core mission of diversity will be incorporated into all workgroups. Additionally, the Ecosystem Steering Group will be formed to support the Swift developer ecosystem, and a Contributor Experience Workgroup will create pathways for open-source contributions. Here’s an overview of all:

Swift Workgroups Diagram

Source: swift.org

And that’s it for May. Have a great week of WWDC 😎 and until next time!

💁🏻‍♂️ Enjoyed this article? Check out TranslateKit! A drag & drop translator for String Catalog files – it’s really easy. Get it now to machine-translate your app to up to 150 languages!

]]> Swift Evolution Monthly: March + April '23 https://evolutionkit.dev/blog/swift-evolution-monthly-mar-apr-23/ https://evolutionkit.dev/blog/swift-evolution-monthly-mar-apr-23/ Mon, 01 May 2023 00:00:00 +0000 Swift Evolution Monthly: March + April '23

It’s already been a whole year since I started writing this newsletter! 🥳 Can you believe it? I’ve had so much fun sharing all of the latest news and updates about Swift with you over the past year. Starting with a recap of the Swift Evolution history in the first issue of the newsletter, I managed to cover as many as 44 proposals already, and with this issue, I’m adding six more, reaching 50!

To celebrate this milestone, I’ve created a GitHub project with all my past summaries shared with this newsletter already. This should make it much easier for anyone in the community to find a specific proposal summary. I designed the repo in such a way that you can simply replace apple in a proposal’s GitHub URL (https://github.com/apple/swift-evolution) with FlineDev and you’ll directly get to the summary of the related proposal!

I also decided that starting with this newsletter, I will also always summarize one old proposal discussed and accepted before this newsletter was even kicked off that I find still relevant and interesting. This way, the repo should become even more useful as a “summary project” for all the sometimes too-detailed proposal documents. And I invite members of the community who already wrote proposal summaries in other places to contribute to the project, too! Or just write a summary for a topic you’ve always been interested in, writing a summary is a great way to learn more about Swift, I can tell from experience! 😉

Thank you so much for being a part of this journey with me so far. Here’s to another great year of Swift Evolution Monthly! 🍻🎉

Accepted Proposals

The first of the newly accepted proposals highly relates to an older proposal I didn’t cover yet. So, I think it’s most natural to start with this old proposal:

SE-0314: AsyncStream and AsyncThrowingStream

Links: **📝 Proposal | 💬 Reviews: 1st, 2nd  |  ✅ Acceptance

We all have used many types conforming to the Sequence protocol, like Array, Dictionary, or String. It allows for easy iteration with  for element in array. The same treatment was added to the new Swift Concurrency world with AsyncSequence, which is pretty much the same as Sequence but the values aren’t immediately available, instead they come at a later time. But usage looks exactly the same, with only the await keyword added: for await element in array.

Actually, there’s one thing wrong with the sample code just provided: array. Because the Array type doesn’t conform to AsyncSequence, instead, we need new types that we can instantiate and return in our APIs, or that we can consume from system APIs. And that’s where AsyncStream and its throwing counterpart AsyncThrowingStream come into play. If you’re not familiar with streams, think of them as “async arrays”. This is a simplification of course, and creating an AsyncStream is quite different from an array. Here’s a simple example:

let swiftFileURL: URL = ...
let matches: (String) -> Bool = { $0.contains("// TODO:") }

let matchingLineNumbersStream = AsyncStream<Int> { continuation in
   Task {
      var lineNumber: Int = 0
      for try await line in swiftFileUrl.lines {
         lineNumber += 1
         if matches(line) {
            continuation.yield(lineNumber)
         }
      }
      
      continuation.finish()
   }
}

Note that we’re being passed a continuation which we pass new values to by calling yield() and when we reach the end of the “async array”, we call .finish(). This way we don’t have to write a custom iterator logic.

Then, consumers like some rule in a linting tool could use the stream like so:

for await lineNumber in matchingLineNumbersStream {
   violatingLines.append(lineNumber)
}

Iterate an Async(Throwing)Stream like you do with any other Sequence type.

The cool thing about AsyncStream is that it’s not only useful for slow APIs, like calling data from a server. But it can also be used when receiving values very fast, faster actually than we can consume them on the call site. AsyncStream automatically buffers values in this case and sends them in the receiving order, so we never skip any values and things work as expected.

SE-0388: Convenience AsyncStream.makeStream methods

Links: 📝 Proposal  |  💬 Review  |  ✅ Acceptance

Currently, when creating an AsyncStream, you get passed a continuation parameter into the trailing closure to send (or .yield) values to. In some cases, this works fine. But in many situations, you actually might want to pass around the continuation to some other places. And this proposal adds that capability:

let (stream, continuation) = AsyncStream.makeStream(of: Int.self)

await withTaskGroup(of: Void.self) { group in
   group.addTask {
      // code using `continuation`
   }
   
   group.addTask {
      // code using `stream`
   }
}

Note the makeStream(of:) method returning a tuple containing the continuation. It’s also worth noting that this is making use of @backDeployed(before:) introduced recently in SE-0376 to make this API available for projects targeting older OS versions than the ones Swift 5.9 will be included in. 💯

SE-0389: Attached Macros

Links: 📝 Proposal  |  💬 Review  |  ✅ Acceptance  |  🔮 Vision

This is a continuation of SE-0382 which introduced “Expression Macros”. While the latter focused on a more function-like structure that we could “call” from anywhere using #, this proposal focuses on “attaching” behavior to existing declarations like functions or types using @. This might remind you of SE-0258 which introduced property wrappers that allowed attaching extra behavior to stored properties like done by SwiftUI with the likes of @State. And, in fact, this similarity is on purpose because, to some extent, “attached macros” are an extension of property wrappers to all kinds of declarations and are explicitly stated as “subsuming some of the[ir] behavior”.

For example, you could declare a “peer macro” named AddCompletionHandler:

@attached(peer, names: overloaded)
macro AddCompletionHandler(param: String = "completionHandler")

Then attach it to any async API like this (overriding the default param name):

@AddCompletionHandler(param: "completion")
func fetchImage(url: URL) async throws -> Image { ... }

The macro would create an overloaded version of the same function with a non-async completion-handler as a parameter for you, for example:

func fetchImage(url: URL, completion: (Image) -> Void) throws {
   Task {
      let image = try await self.fetchImage(url)
      completion(image)
   }
}

The implementation of a macro is a bit involved and requires an understanding of swift-syntax & a new SwiftSyntaxMacros module. But the mere possibility to adjust our Swift code *using *Swift code is very powerful.

In total, there will be 5 different kinds of attached macros:

  1. Peer Macros:
    Attached to declarations to provide additional declarations.

  2. Member Macros:
    Attached to types to add new members (like properties).

  3. Accessor Macros:
    Attached to stored properties to turn them into computed properties with full access to the local context (unlike property wrappers).

  4. Member Attribute Macros:
    Attached to types to apply attributes to all members (similar to @objcMembers or @MainActor).

  5. Conformance Macros:
    Attached to types to add new protocol conformances.

I really liked how Swift improved the developer experience by automatically synthesizing the conformance to types like Codable (SE-0166 + SE-0295), Hashable, or Equatable (both SE-0185). And I’m really happy to see that we are now getting the power of implementing similarly magical APIs ourselves. 🪄

SE-0391: Package Registry Publish

Links: 📝 Proposal  |  💬 Review  |  ✅ Acceptance

This proposal defines all things missing to allow for a unified way of publishing Swift packages to registries like the now officially Apple-backed Package Index:

  • A metadata format for related URLs, authors & organizations.

  • A package signature format for registries that require signing.

  • A new package-registry publish subcommand to “create a package source archive, sign it if needed, and publish it to a registry” all in one go.

  • A set of requirements for registries supporting signing to ensure security.

The good news is that you probably won’t have to learn more about the details of this proposal thanks to the great work of Dave & Sven, plus the support of the Swift community, including these 85 amazing people. All that framework authors might need is the new publish subcommand, maybe not even that unless they use a CI for uploads, cause Apple might ship a UI for it in Xcode. 🤞

SE-0393: Value and Type Parameter Packs

Links: 📝 Proposal  |  💬 Review  |  ✅ Acceptance

This proposal adds two new keywords to the Swift language:

  • each: Precedes a type (like some) & marks it as a “parameter pack”.

  • repeat: Precedes a type/expression & “expands” the related pack.

But what is a “parameter pack” and what does it mean to “expand” one?

In Swift when writing functions that accept a variable number of values of (potentially) differing types, the best we can do if we don’t want to erase their types is to write a generic function like this:

func areEquivalent<A, B, C>(_ first: A, _ second: B, _ third: C) -> Bool

// example usage
areEquivalent("42", 42, 42.0)  // => true

While this function uses generics so we don’t have to write many overloads to the same function with different type specifications, it is restricted to taking exactly three parameters. But what if we wanted an areEquivalent implementation for any number of differing types? To support up to 10 parameters, we would need to define 10 different generic methods like the above, each with a growing number of generic types. But couldn’t we somehow tell Swift to do that for us?

Well, that’s exactly what this proposal does by means of each and repeat:

func areEquivalent<each T>(_ values: repeat each T) -> Bool

A “parameter pack” is what allows a function to accept an arbitrary number of arguments of any type, here: each T. The “expansion” of a pack is the process of unpacking its contents into individual arguments, here: repeat each T. The single function declaration above is “expanded” to function declarations with zero, one, two, three, and more parameters of (potentially) distinct types by Swift.

And that’s not all, there’s much more to this proposal – it’s actually quite detailed. The above is just a short intro to parameter packs, but it doesn’t even show the implementation side of it. Here’s an implementation from the proposal:

func zip<each T, each U>(firsts: repeat each T, seconds: repeat each U) -> (repeat (each T, each U)) {
  return (repeat (each firsts, each seconds))
}

Multiple parameter packs in one function are possible but are inferred to have the same size.

And this seems just the first step into the larger topic of variadic generics programming, a related pitch & a related proposal are listed further below.

✨ Want to see your ad here? Contact me at ads@fline.dev to get in touch.

SE-0394: Package Manager Support for Custom Macros

Links: 📝 Proposal  |  💬 Review  |  ✅ Acceptance  |  🔮 Vision

With SE-0382 “Expression Macros” & SE-0389 “Attached Macros” (⬆️), we’re getting closer to a Swift world full of macros. But what if we wanted to share macros across projects or with the community in an open-source package?

This proposal adds a new target type to the Swift package manifest named macro which has the same shape as other target types like target or testTarget. But it behaves more like the plugin target type added in SE-0303: When included in a project, the macro targets are built as executables so that the compiler can run them as part of the compilation process for any targets which depend on them. Also, like package plugins, the macro target will be executed in a sandbox that prevents file system and network access.

I’m looking forward to the macros the community will come up with, especially if Apple introduces how to use these new features to a wider audience at WWDC.

Proposals in Progress

Recently Active Pitches/Discussions

Other Developments Worth Mentioning

I had already written about the Upcoming Feature flag with which you can try out Swift 6 features in SE-0362. Soon after I wrote this very popular article about how you can use some Swift 6 features today, Swift.org received a very related improvement: Now you can filter proposals with an upcoming feature flag and you’ll even see the feature flag’s name right within the list:

In December 2022 Apple announced that they would be open-sourcing Foundation (or rather rewriting Foundation in the open). Less than 5 months later, they already announced that a preview of this “future of Foundation” is available, focusing on FoundationEssentials and Internationalization. Contributions are welcome! Time to test your apps with it and report bugs.

The second vision document (“A Vision for Macros”) has been accepted and is now included right within the Evolution GitHub repo in the visions folder.

And that’s all for March & April. Until next time!

💁🏻‍♂️ Enjoyed this article? Check out my app RemafoX! A native Mac app that integrates with Xcode to help translate your app. Get it now to save time during development & make localization easy.

]]> Swift Evolution Monthly Jan + Feb '23 https://evolutionkit.dev/blog/swift-evolution-monthly-jan-feb-23/ https://evolutionkit.dev/blog/swift-evolution-monthly-jan-feb-23/ Mon, 20 Mar 2023 00:00:00 +0000 Swift Evolution Monthly Jan + Feb '23

The last issue had an unusual delay already because I had to move the newsletter over from one service to another while I was on travel in Japan. This time around I had to skip an entire month because I had to move my flat from one city to another right after, which was a much much bigger task! 😱📦💪

In fact, I couldn’t work at all for about 5 weeks and the relocation is still not fully completed. But that’s how life is sometimes. At least I have a full workroom to myself now (instead of just a table in my bedroom), which could help to be more productive in the future. Also, I will finally have a real background in my Livetreams instead of having to use a green screen like before (to hide my bed 😂).

Additionally, I’ve decided to change the structure of this newsletter a bit. I noticed that some proposals I summarized went through (sometimes significant) changes during the review process, such as the move operator which was first renamed to take and then later to consume. It’s hard for me to keep up with these changes and edit my summaries (in time), plus edits aren’t even possible for sent emails.

So, starting with this issue, I will be summarizing only the accepted proposals. I’ll treat other proposals like I treated pitches/discussions before and list them in their own section with their title and related links so you can read up on what sounds interesting. The related links will also include the vision document from now on (if one exists), so you can read up on the bigger picture.

Also, I’ve created a new account for this newsletter on both Twitter & Mastodon where I plan on posting even shorter summaries of proposals as soon as I’ve worked through them. I might also send out other Evolution-related posts from time to time, so if you’re interested in more frequent news, make sure to follow: @SwiftEvolutionM (Twitter) / @SwiftEvolutionM@iosdev.space (Mastodon)

With that said, let’s get to the summaries of all proposals accepted in Jan./Feb.:

SE-0382: Expression Macros

Links: 📝Proposal* | 💬 Reviews: 1st, 2nd  |  ✅ Acceptance  |  🔮 Vision*

This new feature will introduce a new kind of function-like structure called an “Expression Macro” which will come in very handy to write more expressive libraries and eliminate boilerplate in code. These new macros work very similarly to functions because they take data through arguments, do something with those data and return some new data. But the big difference is that their execution happens during compile time, which means that the data they operate on is not runtime user data, but it’s the source code of your app (or library)!

Yes, you heard that right, it’s like a little hook we get into the compilation process so we can eliminate having to repeat writing similar code in various places to make things in our code consistent. Because you have access to your source code in macros, they will even allow for new concepts currently impossible to write in Swift. Have you ever used #filePath,  #function, #line, #selector, #colorLiteral, #imageLiteral or other things starting with # in your code? Well, those are all built-in expressions that will be subsumed into macros and ship as macros in the Swift standard library. These should already give you an idea of what kind of features are possible with macros. Here are 9 more use cases for macros:

  1. Domain-specific languages (DSLs) – e.g. mathematics, database queries

  2. Code generation – e.g. JSON to Codable struct

  3. Debugging – e.g. print value of variable before & after a function call

  4. Performance optimization – replace runtime checks with compile-time checks

  5. Syntax extensions – e.g. new control flow constructs or data types

  6. Functional programming – e.g. simulate curried functions

  7. Code instrumentation – e.g. measure performance, monitor usage

  8. Algorithmic complexity analysis – e.g. determine time complexity of sorting

  9. Code obfuscation – e.g. for hard-coded Strings like API keys

It’s hard to tell if this proposal alone already enables all these use cases until we try this new feature out, for example, because the implementation will be sandboxed like with SwiftPM plugins. But at least it’s a big first step toward the larger vision. While this sounds quite exciting, writing a macro has its own learning curve as you’ll have to make use of the swift-syntax library and a new SwiftSyntaxMacros module that will provide what’s required to define macros.

I won’t go into all details of how to implement a macro, but it’s worth noting that there will be two parts to it: The declaration and the implementation. Much like with functions, where func description(count: Int) -> String is the declaration and the code within { ... } is the implementation. But with macros, those two are not necessarily within the same file and can/must be written separately:

import SwiftSyntax
import SwiftSyntaxBuilder
import _SwiftSyntaxMacros

// Implementation:
public struct StringifyMacro: ExpressionMacro {
  public static func expansion(
    of node: some FreestandingMacroExpansionSyntax,
    in context: some MacroExpansionContext
  ) -> ExprSyntax {
    guard let argument = node.argumentList.first?.expression else {
      fatalError("compiler bug: the macro does not have any arguments")
    }

    return "(\(argument), \(literal: argument.description))"
  }
}

// Declaration:
@freestanding(expression)
macro stringify<T>(_: T) -> (T, String) =
  #externalMacro(module: "ExampleMacros", type: "StringifyMacro")

// Usage:
let (a, b): (Double, String) = #stringify(1 + 2)

Sample macro from the proposal. Another macro #externalMacro ties things together.

Doug Gregor from the Language Workgroup is maintaining a GitHub repo with many more sample implementations of macros if you’re interested.

I’m really looking forward to what new expression macros Apple will introduce during WWDC this year, and I’m also sure the community will come up with some creative uses to simplify app coding life, make code safer or streamline the API of their libraries.

SE-0383: Deprecate @UIApplicationMain and @NSApplicationMain

Links: 📝Proposal**| 💬 Review  |  ✅ Acceptance

The ‘Introduction’ section of this proposal summarizes this pretty well:

@UIApplicationMain and @NSApplicationMain used to be the standard way for iOS and macOS apps respectively to declare a synthesized platform-specific entrypoint for an app. These functions have since been obsoleted by SE-0281’s introduction of the @main attribute, and they now represent a confusing bit of duplication in the language. This proposal seeks to deprecate these alternative entrypoint attributes in favor of @main in pre-Swift 6, and it makes their use in Swift 6 a hard error.

There’s not much more to say about it. But you could use this as a reminder to switch from @UIApplicationMain to @main today to prevent the warning and be Swift-6 conformant. Or wait for the fix-it to appear in a future Xcode release.

SE-0384: Importing Forward Declared Objective-C Interfaces and Protocols

Links: 📝Proposal**| 💬 Review  |  ✅ Acceptance

This concerns everyone calling code written in Objective-C from within Swift (like when using older libraries). The idea is to port a common workaround for cyclic dependencies in Objective-C code to Swift in an automatically synthesized way:

In Objective-C, the public API of a type is declared in a header .h file. When a type named User wants to declare a public property credentials which has its own type Credentials, it needs to import its header file  Credentials.h. Now, when the Credentials type had a property named user of type User, it would need to import the header file User.h which is a cycling dependency that is not allowed and causes a compiler error. To fix this, there’s a workaround in Objective-C where one declares an empty type to specify that a specific type “exists” without actually importing its header, this technique is called “forward-declaration”.

To use such Objective-C APIs in Swift, one had to “forward-declare” those types in Swift explicitly, which is very inconvenient. In the future, that won’t be necessary. Swift will automatically synthesize forward-declared types in Swift as follows:

// @class Foo turns into
@available(*, unavailable, message: “This Objective-C class has only been forward declared; import its owning module to use it”)
class Foo : NSObject {}

// @protocol Bar turns into
@available(*, unavailable, message: “This Objective-C protocol has only been forward declared; import its owning module to use it”)
protocol Bar : NSObjectProtocol {}

This new behavior will be turned on by default in Swift 6, but needs to be opted-in with Swift 5.x by using the flag -enable-import-objc-forward-declarations.

📧 To receive future issues via email, subscribe to the newsletter here.

Proposals in Progress

Recently Active Pitches/Discussions

Some threads inside the “Evolution” category with activity within the last 2 months I didn’t link yet. I’ll cover them in detail once (and if) they become proposals:

✨ Want to see your ad here? Contact me at ads@fline.dev to get in touch.

Other Developments worth Mentioning

I’ve already presented several features that will find their way into one of the next Swift versions (e.g. 5.8) but that are opt-in for Swift 5.x and will only be turned on by default in Swift 6, like the last proposal summarized above. In this thread, the Language Workgroup has now clarified the 3 focus areas for all breaking changes planned for Swift 6: Data-race safety by default, performance predictability, and package ecosystem scalability. Read the full post for more details.

Further down in the thread, asked for a rough idea of when we can expect Swift 6, Doug Gregor from the Language Workgroup clarifies that Swift 6 definitely won’t be released within 2023. So there’s still some time until we can expect these opt-in features to be turned on by default.

That’s why I’d like to remind everyone to consider opting into these potentially source-breaking opt-in features as soon as Swift 5.8 is released, which should happen within the next 30 days if history repeats. Like Doug says in the post, by doing so: “Developers will reap the benefits from these improvements sooner, rather than wait until the Swift 6 language version is available and complete.” Which will take a while. See my summary of SE-0362 for how to opt in.

And that’s it for this issue. Til next time!

💁🏻‍♂️ Enjoyed this article? Check out my app RemafoX! A native Mac app that integrates with Xcode to help translate your app. Get it now to save time during development & make localization easy.

]]> Swift Evolution Monthly: December '22 https://evolutionkit.dev/blog/swift-evolution-monthly-december-22/ https://evolutionkit.dev/blog/swift-evolution-monthly-december-22/ Fri, 13 Jan 2023 00:00:00 +0000 Swift Evolution Monthly: December '22

One of the side effects of Elon Musk taking over Twitter was that the provider hosting this very newsletter is being shut down as soon as this month. So, while I’m still traveling Japan (sadly, only a few days left 😔), I had to find a new provider and migrate everything over, which is why this issue comes unusually late. And that’s also why the design and sender of the newsletter will look different if you’re reading this as an email newsletter.

Here’s the new link for the newsletter: https://swiftevolution.substack.com
If you prefer an **RSS **reader, use this: https://swiftevolution.substack.com/feed

I skipped the November issue on purpose, as there weren’t enough interesting new proposals to cover from the perspective of app developers. But December had some interesting ones incoming, and there were even two proposals posted in January, which I will summarize in the next issue. I also decided to move one more proposal summary to the next issue, otherwise, this text would have been too long.

Without further ado, let’s get on with what happened in Nov/Dec!

Accepted Proposals

The following proposal already presented in the past has been accepted:

Proposals In Review/Revision/Waiting

You can still provide feedback for these proposals**. The current rejection rate is **<10%, so they’relikely toget accepted. Revisions are more common.

SE-0378: Package Registry Authentication

Links:Proposal Document**📝 | **Review🧵

Before we get to the news of this proposal, let me first clarify what a “package registry” is, as this newsletter was started after they were accepted to Swift and thus I didn’t cover them yet. SE-0292: Package Registry Service, which was only recently shipped with Swift 5.7 (in Xcode 14), adds an alternative way of declaring package dependencies when using SwiftPM. Instead of using Git and its actions like clone or checkout for fetching dependencies by SwiftPM, the idea of a package registry is to define a RESTful API as an alternative to fetching via Git. A true API like provided by a package registry has performance and reliability advantages compared to using Git for dependency resolution and fetching. The good news is, from an app or framework developers perspective, these details are hidden by SwiftPM and the registry services that implement them. Unless you plan on implementing such a registry service yourself (which might make sense for larger companies, please read the full proposals in that case!), all you need to know is this:

Thanks to SE-0292, starting with Swift 5.7 whenever you add a dependency to your projects using SwiftPM, you can decide to either provide the GitHub URL (which was always possible) or alternatively provide a sort of identifier for the project consisting of a scope and the name of the package, e.g. something like FlineDev/HandySwift. In this example, FlineDev is my personal GitHub organization name which serves as the scope and HandySwift (a lib where I extract my reusable Swift code to) uniquely identifies a convenience library within that scope. Now, SwiftPM will search package registries you’re signed in to in order to find and download a version of my HandySwift library.

Yes, you read that right: You need to first be signed in to a package registry. Also, of course the library needs to be available through that registry. Apple announced that they are actually aiming to (effectively) replace the currently Git-based dependency management with a registry-based one long term. They will cooperate with the already useful Swift Package Index project (a website that helps discover packages, hosts documentation & more), which Dave Werver, one of the projects main contributors, confirmed in his newsletter. This is likely to become a one-stop place for all of Swift developers to get Open Source libraries from which (I can imagine) could even become the default server built into SwiftPM at some point if adoption is high, similar to how things work with CocoaPods already (or RubyGems for Ruby / PyPI for Python / npm for JavaScript). But we’ll see how things will turn out.

Now, the new thing this proposal introduces is another authentication method: Currently, only basic authentication is supported, which limits some interactions. This proposal aims to add token authentication and fixes some security aspects of the current authentication system (no project-level auth file & use Keychain on macOS). I’m happy to hear that we are finally getting closer to having a faster and more reliable Swift dependency management system.

SE-0379: Swift Opt-In Reflection Metadata

Links: Proposal Document 📝 | Review 🧵

Are you making use of reflection APIs in Swift in your apps today? As a reminder: Reflection is the act of building your logic upon the structure of your (or someone else’s) Swift code. For example, for a type Person you could use the Mirror type and pass it an object of type Person to get information about the properties and their names to act accordingly. You might think that this seems useful in some rare scenarios, but I’m sure you’ve used reflection APIs already. If you’ve done any kind of debugging, chances are that you might have used one of the print, debugPrint or dump methods and passed them an object already. Guess what, the reason these give you some useful information is that they are making use of Reflection under the hoods!

But independent of if you’re planning on making use of reflection APIs explicitly sometime in the future or not, this proposal will profit anyone: Because it introduces fine-grained control over when reflection on a type is needed and when it is not and provides compile-time feedback. Basically, up until now, all code had to be compiled in a way that made reflection possible by adding metadata to your app binary, such as the property names firstName and lastName for a type like Person – just in case some library or SDK you were using relied on reflection like SwiftUI does for tracking changes in your model. Of course, this means that it is much easier to reverse-engineer our compiled code back to its original code form with these kinds of metadata than it would be if the name of the property wouldn’t be clear. Also, it is currently possible to completely turn off reflection metadata generation without any compiler warnings, which can lead to unexpected behavior.

This proposal aims to solve that by introducing a new Reflectable protocol to mark types that should support reflection metadata explicitly, so only for those types full metadata is provided. A migration path is provided so existing code doesn’t break immediately. Instead, Swift users will (probably) get a warning at first, so they can migrate their types over to Reflectable. Only once Swift 6 is out, the new behavior will be turned on by default (use the flag -enable-full-reflection-metadata to turn it on before that). For those who want to use reflection explicitly in their own code, they’ll be able to specify that their functions only work on types that conform to Reflectable and this way can be sure they can reflect on the provided data. And for those who just want to use APIs that use reflection under the hood, they will get an error at compile-time if they pass in data that doesn’t conform to Reflectable, making Swift reflection code safer, more reliable, and harder to reverse-engineer all at the same time.

SE-0380: if and switch expressions

Links: Proposal Document 📝 | Review 🧵

Consider this sample code showing a portion of logic for a Chess game app, read especially the comments I’ve added showing different implementation patterns:

class ChessGame {
   enum Direction: CaseIterable {
      case up, right, down, left, upRight, downRight, downLeft, upLeft
   }

   enum Piece {
      case pawn, rook, knight, bishop, queen, king

      // implemented as if-else with multiple returns
      var maxFieldsCanMoveInOneTurn: Int {
         if self == .pawn || self == .king {
            return 1
         } else if self == .knight {
            return 3
         } else {
            return 7
         }
      }
   }

   func movementLogic(of piece: Piece) {
      // implemented as switch-case with multiple returns in a self-executing closure
      let movableDirectionsForWhitePlayer: [Direction] = {
         switch piece {
         case .pawn: return [.up]
         case .rook: return [.up, .right, .down, .left]
         case .bishop: return [.upRight, .downRight, .downLeft, .upLeft]
         case .knight, .queen, .king: return Direction.allCases
         }
      }()

      // implemented as switch-case with Swift's definite initialization feature
      let movableDirectionsForBlackPlayer: [Direction]
      switch piece {
      case .pawn:
         movableDirectionsForBlackPlayer = [.down]
      case .rook:
         movableDirectionsForBlackPlayer = [.up, .right, .down, .left]
      case .bishop:
         movableDirectionsForBlackPlayer = [.upRight, .downRight, .downLeft, .upLeft]
      case .knight, .queen, .king:
         movableDirectionsForBlackPlayer = Direction.allCases
      }

      // …
   }
}

Of course, this code could be refactored in multiple ways, but let’s stick to this code example for educational purposes. There are cases when some developers (including me) actually want this kind of in-line structure, especially if we want to return different but simple and clear values for different cases in code. Well, I have great news for you, because this proposal is doing exactly that and is simplifying the above code in many ways:

First, we no longer need to state the return keyword in if or switch statements if (and only if) all branches have exactly one statement and when the type of this statement is the same for all of them (independently!). Second, we no longer have to write a self-executing closure in these cases anymore, we can directly assign to variables from a if or switch statement. The latter aspect actually is what differentiates a mere statement from an expression: An expression always evaluates to a value, where an if or switch statement is only a structure for conditional code, a statement doesn’t (necessarily) evaluate to a value. But if and switch now will be usable as expressions when returning from functions/properties/closures or when assigning to variables.

With this proposal, the above code can be written as:

class ChessGame {
   enum Direction: CaseIterable {
      case up, right, down, left, upRight, downRight, downLeft, upLeft
   }

   enum Piece {
      case pawn, rook, knight, bishop, queen, king

      // no need for any return keyword
      var maxFieldsCanMoveInOneTurn: Int {
         if self == .pawn || self == .king { 1 }
         else if self == .knight { 3 } else { 7 }
      }
   }


   func movementLogic(of piece: Piece) {
      // no return keyword, no need for self-executing closure
      let movableDirectionsForWhitePlayer: [Direction] =
         switch piece {
         case .pawn: [.up]
         case .rook: [.up, .right, .down, .left]
         case .bishop: [.upRight, .downRight, .downLeft, .upLeft]
         case .knight, .queen, .king: Direction.allCases
         }

      // no return keyword, no need for definite initialization
      let movableDirectionsForBlackPlayer: [Direction] =
         switch piece {
         case .pawn: [.down]
         case .rook: [.up, .right, .down, .left]
         case .bishop: [.upRight, .downRight, .downLeft, .upLeft]
         case .knight, .queen, .king: Direction.allCases
         }

      // …
   }
}

I highlighted the differences in the comments. Isn’t this much cleaner? I personally use self-executing closures from time to time, so now being able to get rid of them alongside the return keyword is really making the code read more naturally to me. Today I prefer to put each return in a switch-case in its own line plus an empty line before the next case for best readability, causing them to become really bloated (see here for example). I’ll for sure consider returning in one line like this in the future!

SE-0381: DiscardingTaskGroups

Links: Proposal Document 📝 | Review 🧵

This one is an improvement to Structured Concurrency in Swift, primarily aimed at improving memory management on the server. If you are new to Swifts’ new concurrency mechanisms such as async/await or with(Throwing)TaskGroup, you might want to read up on the two most relevant proposals’ “Proposed Solution” sections as I can’t summarize them in short here and they are pretty well written: SE-0296 Async/await and SE-0304 Structured concurrency.

In short, this proposal introduces two new TaskGroup variants (we currently have TaskGroup and ThrowingTaskGroup) which do not work like a sequence and thus they don’t conform to AsyncSequence (unlike TaskGroup/ThrowingTaskGroup). Instead, they automatically clean up any child Tasks that complete, and they could  be potentially made to conform to Sendable, which is planned for a future proposal. The new types DiscardingTaskGroup and ThrowingDiscardingTaskGroup are provided as a parameter to the new with(Throwing)DiscardingTaskGroup global function. Other than the already mentioned differences, they work exactly like the previous task group types (and their related global function with(Throwing)TaskGroup).

The automatic child task clean-up nature makes these new types suitable for any situation where events are consumed for a longer period of time while creating (potentially long-running) tasks. The perfect use case for this is an HTTP or RPC server that handles an indefinite amount of requests. It’s not possible to write memory-efficient concurrency code for these kinds of scenarios right now.

It’s impressive to see how Swift on the Server is moving forward steadily over such a long period of time already, and there are still so many more things planned!

📧 To receive future issues via email, subscribe to the newsletter here.

Recently Active Pitches/Discussions

Some threads inside the “Evolution” category with activity within the last 2 months I didn’t link yet. I’ll cover them in detail once (and if) they become proposals:

✨ Want to see your ad here? Contact me at ads@fline.dev to get in touch.

Other Developments worth Mentioning

I noticed that a new process seems to have emerged in Swift Evolution which I would call “Vision-Driven Development”. We’ve always had manifestos in the Swift open-source project, like the StringManifesto or the recently very relevant GenericsManifesto and OwnershipManifesto. Each of these claimed to be a vision for their topic. I’ve also seen sometimes that the first proposal of a related set of proposals was partly used as some kind of vision document, like SE-0350 Regex Type and Overview.

But as the Swift code base grows, the Swift Evolution process evolves and so we got a formalization of these kinds of vision documents. Basically, the proposals directory in the Swift Evolution GitHub repo has been joined by a visions directory. And all vision documents will go through a lightweight (internal) review process before getting officially “accepted” and therefore will be even more reliable than before, where the process of the creation of these documents wasn’t clear.

The first vision already accepted is “Using Swift from C++” (see discussion). Two more prospective vision documents have been posted, one about Variadic Generics (discuss here) and one about Macros (discuss there). This kind of formalization is great to see, as it further streamlines the Evolution process.

Apart from that, there has been some exciting news from Apple regarding Swift: Firstly, the Swift projects focus areas for 2023 were announced on the Swift blog which is well worth a read (related discussion on Swift Forums). I just want to highlight two things that could be easily overlooked: The Documentation Workgroup will include guidelines for writing great documentation into the newly open-sourced “The Swift Programming Language” book, which I really appreciate. And the Language Workgroup will publish detailed documentation including guidelines for proposal authors and reviewers, which I think will help get more developers involved in writing or reviewing Evolution proposals in the future. But there’s much more in the article!

Secondly, Apple has announced that they are open-sourcing Foundation! Okay, not the Foundation code we are using today (which probably has lots of old Obj-C and even wrapped C code anyways), but they are doing the closest thing possible, which is an open-source rewrite of Foundation in Swift which will replace Foundation on Apple platforms in the future. Swift on Server environments will finally get access to all of the same Foundation code.

They will use this opportunity to properly group things into smaller packages, FoundationEssentials becoming an even slimmer version of today’s Foundation. This way you can skip FoundationInternationalization for non-localized projects or things like XML or networking support where you don’t need them. Also, thanks to a new contribution process, you will not only be able to dig into code if you run into bugs and fix them yourself, but you will also be able to contribute entirely new APIs to Foundation.

The year 2023 really looks like an exciting year for Swift developers. I’m hyped!

💁🏻‍♂️ Enjoyed this article? Check out my app RemafoX! A native Mac app that integrates with Xcode to help translate your app. Get it now to save time during development & make localization easy.

]]> Swift Evolution Monthly: October '22 https://evolutionkit.dev/blog/swift-evolution-monthly-october-22/ https://evolutionkit.dev/blog/swift-evolution-monthly-october-22/ Sun, 30 Oct 2022 00:00:00 +0000 Swift Evolution Monthly: October '22

October has been a very busy month for me for two great reasons:

Firstly, my love for the great country of 🇯🇵 Japan and its people has made me plan for a long-term trip to the country for a long time, and this plan just became a reality this month as Japan reopened its borders. I can look back to a month full of planning, packing, and traveling. The cool thing is: I am actually writing these lines from a café somewhere in Tokyo now, the most populated city on earth! 😍

I’ll be here in Japan for the next 3 months, which is a dream come true for me personally. But don’t worry, I’ll be continuing to work on apps and write articles from here. Just focusing on studying Japanese on top of all else. 🤓

Secondly, as I already mentioned in the last issue, October was the month I intended to release my first app as an Indie developer – and so I did!

Say hello to RemafoX, the app on the mission to simplify developer life by providing new workflows for localization when working with Xcode. I wrote a short article on how it can help you here – if you’re very limited on time, make sure to at least watch these GIFs which will give you a good first impression of it.

Here’s what other members of the Swift community had to say about it:

This new localisation tool from Cihat Gündüz looks great. As with any tool that tries to integrate with Xcode, setup is a little long-winded and awkward, but once configured, it’s a breeze to add or edit localisations from directly inside your source. The workflow focuses on Xcode, making it an excellent fit for solo developers or small, developer-heavy teams. If that’s you, there’s a free tier/trial, so check it out!

– Dave Verwer in iOS Dev Weekly (Issue #580)

@RemafoX_App, a tool for Indie Developers to localize their iOS apps, looks pretty strong in terms of functionality but it also has fabulous in-app onboarding help and YouTube instructional videos 👍👍👍

– Marco Eidinger in this Tweet

Also, I couldn’t have summarized my motivation behind writing this app better than this flattering first US review on the Mac App Store:

Extremely well made & documented ‌‌I’ve been using this developer’s open-source BartyCrouch localization tool (which) was wonderful but it took ages for me to set up and (learn). ‌‌ReMafoX solves all of those issues extremely well. It’s beautifully designed, well organized, and exceptionally well documented. Every step is explained in detail, both in the code, in the app, and via YouTube videos.

And this is just the beginning. Each month, one new (requested) feature will be added, the first is already out with full support for Ventura and Objective-C files. If you have any localized projects or thought about localizing yours to reach more customers but you found the process too finicky, give ReMafoX a try.

But enough of my app, let’s get from lifting some of Xcode’s limitations to some interesting new proposals that lift some of Swift’s limitations!

Accepted Proposals

The following proposals not yet presented were already accepted:

SE-0373: Lift all limitations on variables in result builders

Links: Proposal Document 📝 | Acceptance Rationale ✅ |Review 🧵

When writing code in the body of a view in SwiftUI, we can already use a lot of structured programming expressions such as if statements or for-each loops. But we cannot use *everything *that we can use in a function. For example, lazy variables or property wrappers such as @Clamping suggested in this NSHipster article will work in a function, but not in a SwiftUI body.

The reason is that SwiftUI has a ViewBuilder type, which is a result builder. So all  code you write inside the body runs in a different-than-normal Swift environment, inside the SwiftUI DSL to be exact. This DSL (= domain-specific language) code may look like normal Swift code like we write in a function (thanks to SE-0289), but it actually isn’t. What you can do within result builders is restricted, but this new proposal aims to get rid of some of the restrictions – those on variables in particular. In the future, you will be able to write the following code and it will compile fine (without the error in the comments you currently get):

import SwiftUI

struct ContentView: View {
   var body: some View {
      GeometryReader { proxy in
         // ⬇ 'Cannot declare local wrapped variable in builder'
         @Clamping(10...100) var width = proxy.size.width
         Text("Hello World").frame(width: width)
      }
   }
}

‌The full list of removed limitations on variables in result builders is:

  • Uninitialized variables (e.g. let x: Int – with exceptions like SwiftUI)

  • Default-initialized variables (e.g. var comment: String?)

  • Computed variables (get & set)

  • Observed variables (willSet & didSet)

  • Variables with property wrappers (e.g. @Clamping(1..10) var count = 12)

  • lazy variables (e.g. lazy var max: Int = { ... })

I have not personally wanted to use any of these yet, but I’m glad that more restrictions were lifted for those situations where we actually do need them.

SE-0375: Opening existential arguments to optional parameters

Links: Proposal Document 📝 | Acceptance Rationale ✅ |Review 🧵

First, let’s remember that an ‘Existential’ is something like an auto-generated “placeholder box type” when working with variables of a Protocol type – see also my more detailed explanation in the April issue here. Now consider this code:

func persist<T: Codable>(_ codable: T?, key: String) {
   if let codable {
      storageDict[key] = try! JSONEncoder().encode(codable)
   } else {
      storageDict.removeValue(forKey: key)
   }
}

func valueChanged(value: any Codable, key: String) {
   // ⬇ 'Type 'any Codable' cannot conform to 'Codable''
   persist(value, key: key)
}

Currently, we get an error when trying to pass the existential any Codable to the persist method which accepts a specific type T that conforms to Codable. Thanks to this new proposal, this will compile in the future as value here is a non-optional and therefore the underlying type can be determined and T is clear.

Proposals In Review/Revision/Awaiting Decision

You can still provide feedback** for these proposals**. The current rejection rate is **<10%, so they’relikely toget accepted. Revisions are more common.

On to new proposals in review/revision/awaiting decision!

SE-0374: Add sleep(for:) to Clock

Links: Proposal Document 📝 | Review 🧵

When introducing the new Clock, Instant and Duration types with SE-0329 (see my summary), it seems that one important method on the Clock type was forgotten: A sleep(for: Duration) method. This caused a problem when Brandon Williams and Stephen Celis from Point-Free used these new APIs to write tests and control time in them for fast unit testing. The reason for their problem was that the existing method sleep(until: Instant) didn’t allow for using an existential clock type to switch out the real-time Clock in tests with a custom fast-forwardable Clock due to the type-erased Instant needed for the sleep(until: Instant) method.

With this proposal they added a new sleep(for: Duration) method that has no such problem. I’m glad that the community has such great members who play around with new APIs even before they are released so they can already propose a fix to some rough edges before most of us even had a chance to try them out.

Not only have they fixed the Swift API for us, but they also open-sourced a new library which comes with 3 Clock types included: TestClock for unit tests, ImmediateClock for SwiftUI previews and UnimplementedClock for mocking!

SE-0376: Function Back Deployment

Links: Proposal Document 📝 | Review 🧵

This proposal suggests adding a new @backDeploy(before: ...) attribute to Swift which none of us app or framework developers will ever need. It’s only relevant for those working on system libraries shipped with the OS like SwiftUI or Charts, but this new attribute might still have a big influence on app developers, too:

Once available, Apple could start introducing new APIs not only for the shiny new operating systems (e.g. iOS 17 & macOS 14) but they could also back-deploy some of the new APIs to older OS versions at the same time. App developers then wouldn’t need to do anything specific to use back-deployed functions. Quite the opposite, they will be able to avoid availability checks and fallback code like this:

// without back-deployment
if #available(iOS 16.0, *) {
   callSomeShinyNewFunction()
} else {
   // fallback on older systems
}

// with back-deployment
callSomeShinyNewFunction()

When using a function marked with @backDeploy the compiler will intelligently check the target SDK of the app being built against and if it’s a version that natively supports the new feature, it will use the system framework, mitigating app binary size increases and each app shipping with its own copy of the function.

Now, don’t get too excited though. While this is really cool and could mean more new APIs will be available to use for teams who need to support OS versions 1-2 years back, there are still limitations. This proposal only discusses adding the attribute for functions, subscripts, and properties without storage. Types like enums and structs or protocol conformances aren’t discussed yet, they are only mentioned as potential future directions.

Also, there are restrictions on which functions can be back-deployed, such as that they need to be statically dispatchable (e.g. final), which excludes all functions that are marked to be compatible with Objective-C via @objc. This means that it will be easier for Apple to back-deploy APIs in newer Swift-only frameworks like SwiftUI, Combine or Charts than it will be to do so with older Objective-C-based frameworks like UIKit & AppKit. Also, we don’t know how many teams within Apple will make use of this new feature and how far back they will be able to back-deploy. Only time can tell. But it’s exciting to see this topic is getting some love!

SE-0377: borrow and take parameter ownership modifiers

Links: Proposal Document 📝 | Review 🧵

This proposal gives Swift authors who are highly concerned about the performance of their code fine-grained control over some aspects of Automatic Reference Counting, the memory management feature of Swift. Two new parameter modifiers (like inout) are introduced for that, namely borrow and take.

The vast majority of app developers won’t need to use these modifiers and should instead trust Swift’s built-in memory management heuristics. For those who are interested, please read the full proposal to fully understand the new modifiers.

📧 To receive future issues via email, subscribe to the newsletter here.

Recently Active Pitches/Discussions

Some threads inside the “Evolution” category with activity within the last month I didn’t link yet. I’ll cover them in detail once (and if) they become proposals:

✨ Want to see your ad here? Contact me at ads@fline.dev to get in touch.

Other Developments worth Mentioning

The Language Workgroup did some clean-up on 6 old proposals with unclear status, of which 3 were returned to discussion and 3 were rejected outright.

Slava Pestov announced a documentation book series digging into the details of how Swift generics work. If you’re curious about this topic or if you (want to) work on the Swift compiler in general, you might want to read the free PDF posted here.

In the last issue I had already mentioned that parts of Swift are rewritten in Swift. But what I had totally missed is that also the parser for the SwiftSyntax library is currently being rewritten in Swift to get rid of the need for the C++ library lib_InternalSwiftSyntaxParser in tools like SwiftLint or BartyCrouch. This [October update post](https://forums.swift.org/t/october-update-on-the-new-swift-parser/61071) summarizes the progress on this front and JP Simard also shared his experiences with the new parser in the same thread.

Speaking of C++ and updates, the C++ Interoperability Workgroup has shared their 8-months progress report.

Lastly, Sima Nerush, a student at Reed College, took some time to write about her experiences and learnings as part of the Swift Mentorship Program where she helped fix 4 bugs in Swift. If you’re interested in becoming an active contributor to Swift yourself, set yourself a reminder for June next year when interest surveys are likely to reopen. The program is open to everyone, not just students!

And that’s it from my October update!

💁🏻‍♂️ Enjoyed this article? Check out my app RemafoX! A native Mac app that integrates with Xcode to help translate your app. Get it now to save time during development & make localization easy.

]]> Swift Evolution Monthly: September '22 https://evolutionkit.dev/blog/swift-evolution-monthly-september-22/ https://evolutionkit.dev/blog/swift-evolution-monthly-september-22/ Thu, 29 Sep 2022 00:00:00 +0000 Swift Evolution Monthly: September '22

After multiple months full of really impactful and fast-paced changes to Swift, such as all the improvements to Generics, the introduction of a shiny new Regex engine, and kicking off the next chapter of programming with distributed actors, things have slowed down a bit in the last two months. This is also the main reason why there was no dedicated monthly issue for August (also, I focused on my first app, which is now scheduled for release on October 11th).

If you are an app developer, probably none of the new proposals I’m summarizing down below is going to cause a “Wow!” reaction, at least it didn’t do that for me this time. But I tried to still understand and explain the meaning or direction of each proposal without getting into irrelevant details for app developers.

More interesting topics await you in the Pitches section, which I always sort by my guessed likeliness of interest to the community and limit to a dozen pitches, adding a few more this time as this issue is spanning two months. So if you don’t have much time but you still want to know what might be coming next, try reading some of the pitches. The community is discussing great ideas constantly!

Accepted Proposals

The following proposals already presented in the past have been accepted:

On to not yet presented but already accepted proposals!

SE-0367: Conditional compilation for attributes

Links: Proposal Document 📝 | Acceptance Rationale ✅ |Review 🧵

Conditional compilation is a language feature very much needed when supporting multiple SDKs (e.g. #if os(iOS)) in an app or multiple Swift versions (e.g. #if swift(>=5.6)) in a framework. The most common use case probably is an #if DEBUG for code that we only want to run during development, but not in production (such as additional logging or different API targets or tokens).

But currently, if you wanted to conditionally use Swift attributes such as @objc or the newer @preconcurrency (for code that was written without Swift Concurrency in mind, see SE-0337), you’d have to duplicate the code for the entire thing the attribute applies to, such as for an entire type like in this example:

#if compiler(>=5.6)
   @preconcurrency
   protocol P: Sendable {
      func f()
      func g()
   }
#else
   protocol P: Sendable {
      func f()
      func g()
   }
#endif

From Swift 5.8 onwards we will be able to shorten that code to just this:

#if hasAttribute(preconcurrency)
   @preconcurrency
#endif
protocol P: Sendable {
   func f()
   func g()
}

Note the new hasAttribute conditional directive. This not only prevents duplicate code but also more clearly states why we were using a conditional compilation here (because of the attribute!) and saves us the time of having to look up which Swift version the attribute was introduced in.

SE-0368: StaticBigInt

Links: Proposal Document 📝 | Acceptance Rationale ✅ |Review 🧵

Unless you’re working on a mathematical app or framework, you probably won’t need to know about the new StaticBigInt type introduced here. But if you do, you might want to read the full proposal (it’s short enough) to learn how you can define your own large integer types that support literals that don’t fit into [U]Int64.

Maybe also worth noting that the official swift-numerics library might soon get larger integer types such as [U]Int256 once this was accepted.

SE-0369: Add CustomDebugStringConvertible conformance to AnyKeyPath

Links: Proposal Document 📝 | Acceptance Rationale ✅ |Review 🧵

This proposal aims at improving the printing of key paths such as in print(\User.name) from currently resulting in Swift.KeyPath<User, String> which is not very useful, to result in something closer to the call like \User.name.

This small improvement could help in debugging and make unit tests clearer.

SE-0370: Pointer Family Initialization Improvements and Better Buffer Slices

Links: Proposal Document 📝 | Acceptance Rationale ✅ |Review 🧵

This is a low-level programming improvement that is not relevant for most app developers. For those interested in low-level, the title should clarify the topic.

SE-0372: Document Sorting as Stable

Links: Proposal Document 📝 | Acceptance Rationale ✅ |Review 🧵

Imagine you have an array of books in code, something like this:

var books: [Book] = [
   .init(author: "Robert Galbraith", title: "The Cuckoo's Calling"),
   .init(author: "J. R. R. Tolkien", title: "The Fellowship of the Ring"),
   .init(author: "J. R. R. Tolkien", title: "The Two Towers"),
   .init(author: "J. R. R. Tolkien", title: "The Return of the King"),
]

And you call books.sort(by: { $0.author < $1.author }), you would expect that the three Lord of the Rings books from J. R. R. Tolkien would be sorted above the first Cormoran Strike book by J. K. Rowling, right? You’re right, of course.

But would you also expect the three Lord of the Rings books to remain in the right order, starting with “The Fellowship of the Ring”? I guess you would. It’s how humans would naturally sort. But technically speaking, all three Lord of the Rings books have the same author, and therefore the sorting criteria treats them all like they’re on the same level. How elements that are on the same level are treated depends on the sorting algorithm. Algorithms that preserve the order of equal-level elements are called “stable”.

In Swift, the sort function has been implemented as a “stable” algorithm for multiple years now, but it was never documented to be. So in theory, the implementation of future versions could have changed to a non-stable algorithm. Not anymore: This proposal documents the sort function’s behavior to be stable.

Proposals In Review/Revision/Awaiting Decision

You can still provide feedback** for these proposals**. The current rejection rate is **<10%, so they’relikely toget accepted. Revisions are more common.

These proposals already presented in the past were returned for revision:

On to new proposals in review/revision/decision!

SE-0371: Isolated synchronous deinit

Links: **Proposal Document**📝 | **Review🧵 | Revision Rationale 🔁

This proposal is another one that probably won’t sound like a huge deal to most app developers. Especially because most didn’t have the chance to make full use of actor types yet (including myself). Introduced with SE-306 in Swift 5.5, they help deal with concurrently executed logic that “acts” on the same data in parallel. A good sign that you should probably consider using them more is when you have classes as data models in your app. Chances are that you might be accessing them simultaneously. And migrating them over to actor types should be possible, given that actors are also reference types like classes.

In Swift, it’s common for types that hold onto other data or dependencies to automatically get rid of these in a deinit method, rather than requiring a close() like method that needs to be explicitly called. When initializers were settled in the Swift actor world with SE-0237, the deinitializer’s access was limited to Sendable stored properties only. All value types ( enums, structs) and all immutable reference types ( classes) can be easily marked as Sendable, which means the data is safe to pass across threads. This proposal weakens that limitation by being smart about the details of the state without compromising safety. This allows a deinit function to additionally access some non- Sendable state, preventing the need of having to provide a close() function or do internal reference counting.

While I don’t fully understand this proposal’s impact even after reading it twice, it sounds a lot like a “rounding things off” kind of proposal to me, which we will all appreciate once we got more used to writing actor types. Currently, I guess, it mostly affects Server-side Swift developers and lower-level framework authors.

📧 To receive future issues via email, subscribe to the newsletter here.

Recently Active Pitches/Discussions

Some threads inside the “Evolution” category with activity within the last 2 months I didn’t link yet. I’ll cover them in detail once (and if) they become proposals:

✨ Want to see your ad here? Contact me at ads@fline.dev to get in touch.

Other Developments worth Mentioning

It’s great to see that there are plans to implement parts of the Swift compiler in Swift (I know, it sounds like an infinite recursion to use Swift for Swift, but it works because the latest development Swift is built with the latest stable release Swift, which was at some point built without any Swift involved [mostly C++]).

The 6 currently existing workgroups (Language, C++ Interoperability, Server, Swift.org website, Documentation, and Diversity) might soon be joined by new groups: Besides Numerical/ML mentioned in the May issue already, one for Swift Tooling and one for broader Platform Support were recently discussed. I also found an older discussion about an Embedded/Bare Metal/Low Resources group. All of these groups make a lot of sense to me, so I hope they will be successful!

That’s it from my September update!

💁🏻‍♂️ Enjoyed this article? Check out my app RemafoX! A native Mac app that integrates with Xcode to help translate your app. Get it now to save time during development & make localization easy.

]]> Swift Evolution Monthly: July '22 https://evolutionkit.dev/blog/swift-evolution-monthly-july-22/ https://evolutionkit.dev/blog/swift-evolution-monthly-july-22/ Wed, 03 Aug 2022 00:00:00 +0000 Swift Evolution Monthly: July '22

Here we are again with another monthly summary of Swift Evolution. July was a very special month for me, so I’d like to start with two topics that are important to me personally. I hope you’ll excuse that – but both are still on-topic:

Firstly, my very first app as an Indie Developer, which I’ve been working on for six months now, is finally done and in Open Beta! It’s an app for Swift developers and improves the localization workflow in Xcode. In the first version, among other things, you can add new localized keys to your projects in multiple languages without ever leaving your Swift file and safely reference them in code – just by filling out a single form! The app will take care of adding entries to all the right files and even optionally machine-translate to multiple languages, see this GIF:

A GIF showing how you can add a new key to your app with RemafoX.

If this looks interesting to you, please try the beta and send me your feedback.

Secondly, one day after sending out the previous issue of this newsletter, I wrote my very first own Swift Evolution pitch. In the thread, I’m requesting a new syntax to improve the usage of the Result type as an alternative for Swift’s native error handling. In the above-mentioned app project, I preferred to have typed errors in order to vastly improve my error handling experience by forcing me to handle all possible error cases with a useful message. But Swift currently doesn’t support typed throws, so I used Result instead and migrated all my throwing functions in the above-mentioned app to it. I’ll be writing about my approach in detail soon on my dev blog if you’re interested. But I came across two safety & convenience issues that I couldn’t fix without changes in the language itself. Thus, the pitch.

If my pitch sounds like something you’d want to have in Swift, don’t get too excited though. Even though I tried to scope it clearly and I tried to make the change as small and language-fitting as possible, I quickly received a lot of refusing comments due to historical discussions on typed throws, even though my pitch is just about adding convenience & safety to Result – to improve things already possible in Swift today. In fact, the topic of typed throws seems to be one of the most controversial topics on Swift Evolution, which I learned the hard way in this thread. This was not the great first-pitch experience on Swift Evolution that I was hoping for to write about in this issue of the newsletter.

Thankfully, after explaining my specific use case and clarifying that my intention was not to rehash any historical discussions, the topic of the thread changed from a judging “there’s no problem in the language, you’re just using it wrong” to a more accepting “let’s explore how we can improve the valid use case you described” kind of vibe. I hope it stays like that and even more, I wish it was like that from the start. It’s hard for me to motivate anyone in the developer community to be more active in the forums with their own pitches if I have to add to that that they should be cautious not to run into some of the difficult topics. But here we are.

I’m sure, the whole thing was a misunderstanding and I probably didn’t communicate things clearly enough on my end. But in any case, this is a good opportunity to remind everyone (including me!) to always initially expect others to have good intentions and to respect the decisions they made for themselves. This is much better than expecting the worst and judging their decisions by making assumptions about their situation based on your own past experiences. It might be tempting to do that sometimes as it can simplify your life, but it’s not always right and can even hurt people. After all, people are different, situations are different, therefore solutions will always be different, too. A “general purpose language” like Swift and the community around it should accommodate that.

With this longer comment this time, let’s get on to this month’s proposals!

Accepted Proposals

The following proposals already presented in the past have been accepted:

Proposals In Review/Awaiting Decision

You can still provide feedback for these proposals. The current rejection rate is <10%, so they’re likely to get accepted. Revisions are more common.

The following proposals already presented were returned for revision:

On to new proposals currently in review (or still awaiting a decision)!

SE-0363: Unicode for String Processing

Links: Proposal Document 📝 | Review 🧵

This is the last of the six Regex String-Processing proposals that were explored with the swift-experimental-string-processing package on GitHub before they were turned into a set of proposals. I covered them all in past issues (1, 2, 3, 4, 5) and they were all accepted already. Some of them have shipped as part of the Xcode 14 betas, it’s worth mentioning this year’s WWDC sessions Meet Swift Regex & Swift Regex: Beyond the basics again as they provide a great introduction to the topic.

This last proposal explains all the details of how Swifts Regex engine supports Unicode by default, which is not the case for many Regex engines. It also goes into the details of how character classes (which can be thought of as a Swift-native version of Foundations CharacterSet class) such as .digit, .whitespace and .wordCharacter are defined and how you can adjust them to fit your needs.

Here are a few key points worth pointing out:

  • Swift will do “grapheme cluster matching” by default in its Regex engine – this means that the Regex Caf. (the . matching “any” single character) will match Café always correctly – unlike e.g. C#, Rust, Go, Python, Objective-C, Java*, Ruby, and Perl which would just match Cafe without the acute accent on top of the “e” for an é that consists of multiple Unicode scalars ( "\u{65}\u{301}").

  • If you need “Unicode scalar” level matching semantics (e.g. for compatibility):

"Café".contains(/Café/.matchingSemantics(.unicodeScalar)) // => false

  • By default, the grouping of characters into character classes follows the modern Unicode Technical Standard #18. But custom matching behaviors can be provided, such as .ignoresCase(), dotMatchesNewlines(), anchorsMatchNewlines(), and asciiOnlyClasses(). Advanced Regex users might find [defaultRepetitionBehavior()](https://github.com/apple/swift-evolution/blob/main/proposals/0363-unicode-for-string-processing.md#eagerreluctant-toggle) very handy.

  • The available character classes are: .any (= .), .anyNonNewline (= .), .anyGraphemeCluster (= \X), .digit (= \d), .hexDigit, .word (= \w),  .whitespace (= \s), .horizontalWhitespace (= \h), .verticalWhitespace (= \v), .newlineSequence (= \n or \R).

  • Character classes can be inverted, for example:
    .digit.inverted (= \D) and .word.inverted (= \W)

  • Like with Foundations CharacterSet class, you can build a union or intersection of two character classes or you can be  subtracting one from another and even build their symmetricDifference. You can also specify custom classes with the .anyOf and noneOf static methods. For example:

let floatingNumber: CharacterClass = .digit.union(.anyOf(".,"))

SE-0364: Warning for Retroactive Conformances of External Types

Links: Proposal Document 📝 | Review 🧵

Do you have code in your projects that extends a type from Apple or Swifts standard library to make them conform to the likes of Equatable, Identifiable, Hashable, or Codable? Did you know that it is discouraged to extend external types with custom conformances to these protocols? The reason is that in case Apple or the Swift community decides to add conformance to the type in the original framework, it’s currently undefined which of the two implementations (yours or the frameworks) will be used, which can lead to unexpected behavior in your app. Note that this is only a problem for users who upgrade to a newer version of the OS but have a version of your app installed that you have not built with the new version of Xcode.

In my current project, I did a quick search on the left sidebar “Find -> Regular Expression” by pasting extension \w+: (Equatable|Identifiable|Hashable|Codable) and I found this extension, which I need because I use TCA which requires my view state types to be Equatable, and I need a Binding in some of them:

extension Binding: Equatable where Value: Equatable {
   public static func == (left: Binding<Value>, right: Binding<Value>) -> Bool {
      left.wrappedValue == right.wrappedValue
   }
}

This proposal suggests showing a warning in all places where you are extending an external type with these kinds of conformances. The idea is to make developers more aware of this potential issue and convince them to re-consider conforming an external type. To silence the warning you would add the module name in front of each involved type explicitly like so (note the SwiftUI. and Swift. prefixes):

extension SwiftUI.Binding: Swift.Equatable where Value: Swift.Equatable {
   public static func == (left: SwiftUI.Binding<Value>, right: SwiftUI.Binding<Value>) -> Bool {
      left.wrappedValue == right.wrappedValue
   }
}

SE-0365: Allow implicit self for weak self captures, after self is unwrapped

Links: Proposal Document 📝 | Review 🧵

Since Swift 5.3 it is possible to write a closure and capture [self] in order to not have to write self. in front of every call on properties and functions of the current type within the body of the closure (thanks to SE-0269) like this:

button.tapHandler = { [self] in
   dismiss()  // no need to write `self.dismiss()`
}

This proposal aims to introduce this same behavior for [weak self] as well when and only after the Optional of self is unwrapped. So for example a guard let self = self else { return } (or the newly possible guard let self { return }) would make self. calls for properties and functions unnecessary:

button.tapHandler = { [weak self] in
   guard let self { return }
   dismiss()  // no need to write `self.dismiss()`
}

SE-0366: Move Function + “Use After Move” Diagnostic

Links: Proposal Document 📝 | Review 🧵

ℹ️ UPDATE: The move keyword was renamed to consume after reviews.

This proposal adds a new move keyword that gives developers of performance-sensitive code more fine-grained control over when a variable or parameter should be released from memory. The compiler will then ensure a “moved” variable or parameter is no longer accidentally used unless a new value is reassigned to it explicitly. Most app developers won’t ever need to use this keyword, but for those interested here’s a function demonstrating the use of the move keyword:

func f(inout x: Int = 5) -> Int {
   print(x)  // => "5"
   
   let y = move x + 1
   print(x)  // error: 'x' used after being moved
   print(y)  // => "6"
   
   var z = move y
   print(y)  // error: 'y' used after being moved
   print(z)  // => "6"
   
   move z
   print(z)  // error: 'z' used after being moved
   
   z = 10
   print(z)  // => "10" (reassigned a new value to 'z', no error)
   
   x = z
   print(x)  // => "10" (reassigned a new value to 'x', no error)
   
   return z
}

Recently Active Pitches/Discussions

Some threads inside the “Evolution” category with activity within the last month I didn’t link yet. I’ll cover them in detail once (and if) they become proposals:

✨ Want to see your ad here? Contact me at ads@fline.dev to get in touch.

Other Developments worth Mentioning

As the introductory comment was long, I’m keeping this section short:

  • Some pitches seem to get discussed and “guided” proactively in a different direction by the new Language workgroup. To see how often this happened in the past I did a quick search for “The Language Workgroup / Core Team discussed this”, revealing only this and that comment. I’ll keep an eye on it.

  • A Documentation Workgroup, which I reported in the May issue as currently being discussed, has now been officially announced. The details are still in planning, but if you’re interested “use the @swift-documentation-workgroup handle to reach out to the workgroup directly in forums”.

That’s it from the July update!
(Sent a bit later this time because I’m currently on vacation. 🌴)

💁🏻‍♂️ Enjoyed this article? Check out my app RemafoX! A native Mac app that integrates with Xcode to help translate your app. Get it now to save time during development & make localization easy.

]]> Swift Evolution Monthly: June ’22 https://evolutionkit.dev/blog/swift-evolution-monthly-june-22/ https://evolutionkit.dev/blog/swift-evolution-monthly-june-22/ Sun, 26 Jun 2022 00:00:00 +0000 Swift Evolution Monthly: June ’22

WWDC22 brought so many new APIs that despite me watching and summarizing over 20 sessions in just the first week, I still haven’t watched all sessions I marked as favorite yet and am still watching 5–10 sessions a week. But I’m almost done now and my overall impression is that this year we got a lot of developer ergonomics improvements both in SwiftUI & Xcode and even the biggest star of the conference — the new Charts framework — adds to that.

Apple engineers also did a great job of introducing some of the new Swift features that are shipping with Swift 5.7, some of which we have covered in past issues of this newsletter. Here are some you might be interested in:

But let’s get back to what’s new in Swift Evolution to learn about some proposals that are also all going to improve developer ergonomics!

Accepted Proposals

The following proposals already presented in the past have been accepted:

Proposals In Review/Revision/Awaiting Decision

For the following proposals, you can still provide feedback. The current rejection rate is less than 10%, so it’s likely they get accepted. Revisions are more common.

The following proposals already presented were returned for revision:

On to new proposals currently in review (or still awaiting a decision)!

SE-0359: Build-Time Constant Values

Links: Proposal Document 📝 | Review 🧵**

Have you ever found it inconvenient that initializing a URL with a clearly valid String literal like [https://apple.com](https://apple.com/) returned an Optional? I did. I actually always force-unwrap them using by appending !. But no more!

This proposal adds a new **@const** attribute to type properties, function parameters, and even protocols. This will allow restricting APIs to only accept values that are** known at compile-time** — so basically, we will only be able to pass literal values to them. Future proposals will then be able to add functionality into the toolchain that will allow us to add validity checks at build-time for APIs that are marked with @const, preventing us from shipping incorrect code. It also helps the Swift compiler further improve build time.

But that’s not all: This will allow for entirely new ways of using Swift, where merely building the code (but never executing it!) provides enough value, such as for the Swift package manifest file, which already has a pre-pitch to get the same treatment as Regexes have just gotten: A DSL-style syntax!

Does that mean we will be able to write a DSL language that can be easily used as a replacement for config file formats like YAML? Probably. The example mentioned in the proposal is a “build-time extractable database schema”. This is how a new Swift persistence framework could work. 😍

SE-0360: Opaque result types with limited availability

Links: Proposal Document 📝 | Review 🧵**

This basically widens the applicability of SE-0244: Opaque Result Types to very simple if #available checks which is useful for framework authors. For example, the following example currently doesn’t compile because the some Shape opaque result type requires that the body returns exactly one specific type, but we have two different return types (Rectangle and Square):

With this proposal, the above code would compile. But don’t get too hyped, the following already doesn’t compile due to the dynamic if condition:

So in most cases, you will still need to resort back to existential any (SE-0335) or other means of type erasure if you have multiple return types. By the way, I strongly recommend watching the WWDC22 session Embrace Swift generics if you struggle with the new some and any keywords and when to use which. It starts with a quick introduction to protocol-oriented programming, goes into how you can replace where T: Animal with some Animal, and then explains the differences between some and any pretty well.

SE-0361: Extensions on bound generic types

Links: Proposal Document 📝 | Review 🧵**

This is another proposal for making generics more ergonomic by allowing a more natural and expected syntax when using them. In this proposal, extensions are tackled. In short, all of the 3 following extensions statements on a generic type would in the future compile and have the same meaning:

Note that this will only work if all generic type arguments are provided, so if you have a type with multiple generic types and you just want to specify one in your extension, you’d have to resort back to the where clause.

As you can see in the above examples, even syntactical sugar variants will be supported, including optionals. So you’ll be able to write extension String?instead of extension Optional where Wrapped == String.

SE-0362: Piecemeal adoption of future language improvements

Links: Proposal Document 📝 | Review 🧵**

Source-breaking changes in Swift are handled with great caution. So much so, that some new language features are already implemented and shipped with versions of Swift 4/5, but are disabled because they are marked as “only available in Swift 6 language mode”. Some of them shipped with a custom feature flag to turn them on today but even they are hard to explore.

This proposal streamlines that by adding the feature flag specifier --enable-future-feature and requiring all future & even past proposals to adopt this by specifying their own feature identifier for it. This way developers have a unified way to enable and adopt select new features at their own pace.

This not only gives you the benefit of a Swift 6 improvement today but also allows you to easily prepare for Swift 6 on a step-by-step basis. I encourage you to turn on each feature one by one to see its impact to your code base as soon as the unified flags are available. This way you can discuss each feature with your team and create a roadmap for when to enable them to smoothen your transition to Swift 6 proactively.

Thanks to a new #if hasFeature() check, it will even be possible to keep two versions of the same code to not have to change your code when enabling/disabling a feature or simply to support the integration of your framework into tools where the feature is not available. For example:

The adoption of specific features will also be possible by specifying an array of feature identifiers to a target in SwiftPM manifest files like so:

Here’s a list of all initial feature identifiers that are planned to be supported:

✨ Want to see your ad here? Contact me at ads@fline.dev to get in touch.

Recently Active Pitches/Discussions

Some threads inside the “Evolution” category with activity within the last month I didn’t link yet. I’ll cover them in detail once they become proposals:

  • **is case: pattern-match boolean expressions: **Discussion 🧵

  • In-Line Tests: Discussion 🧵

  • **Introduce type-private access level: **Discussion 🧵

  • Eliding some in Swift 6: Discussion 🧵

  • Move Function + “Use After Move” Diagnostic: Draft **📝 | **Discussion 🧵

  • SPM: Allow targets to depend on products in package: Discuss 🧵

  • Conditional compilation for attributes and modifiers: Discuss 🧵

  • Expose property name to property wrapper: Discuss 🧵

  • Use some as “some specialization of generic type”: Discuss 🧵

  • #if hasSymbol compile time check for availability: Discuss 🧵

  • **Isolated synchronous deinit: **Discussion 🧵

💁🏻‍♂️ Enjoyed this article? Check out my app RemafoX! A native Mac app that integrates with Xcode to help translate your app. Get it now to save time during development & make localization easy.

]]> Swift Evolution Monthly: May ’22 https://evolutionkit.dev/blog/swift-evolution-monthly-may-22/ https://evolutionkit.dev/blog/swift-evolution-monthly-may-22/ Fri, 20 May 2022 00:00:00 +0000 Swift Evolution Monthly: May ’22

Last month I presented the first two Regex (or String-processing) related proposals, stating that they are just “kicking off a series of Regex-related proposals”. And here we are, Regexes still being the main focus — and they will probably still be in next month’s issue.

But that doesn’t mean nothing else happened on Swift Evolution. There’s a very interesting proposal for adding Snippets support to SwiftPM. Also, multiple entirely new pitches were made by the community, some of which I’m linking below. And there’s also news on the organizational front.

Read on to learn more about all these developments!

Accepted Proposals

The following proposal already presented in the past has been accepted:

No other proposals were accepted within the last month!

Proposals In Review/Revision

For the following proposals, you can still provide feedback. The current rejection rate is less than 10%, so it’s likely they get accepted. Revisions are more common.

The following proposals already presented were returned for revision:

On to new proposals in review!

SE-0354: Regex Literals

Links: Proposal Document 📝 | Review 🧵**

Regex literals will provide a safer way to define regular expressions than passing a pattern String: While a pattern String can only be checked for syntax errors (such as an opening brace ( without a closing brace )) during runtime (= when the code is executed by the user), the literal can be checked at compile-time (= when you build your app) and therefore it will help reduce crashes for your users or error handling code for you because you don’t have to catch any errors. The syntax will look familiar to those experienced in languages like Ruby, Perl, or JavaScript:

Then, in your documentation comments, instead of placing sample code via three backticks, you’ll be able to just use the new DocC directive @Snippet:

This will place the **presentation code **of your snippet file right into the documentation view within Xcode or add it to your HTML file. What is the presentation code, you ask? Well, because all snippet files will be Swift files that we will be able to compile via swift build --build-snippets (and library authors should make sure to run that on their CI), you might need to write some helper code that is just churn and might not be relevant to showing off your functionality. The proposal gives us a way to hide some parts of our code, for that we simply add // MARK: HIDE and // MARK: SHOW:

We will also get a new [ranges](https://github.com/apple/swift-evolution/blob/main/proposals/0357-regex-string-processing-algorithms.md#ranges) function saving us from writing a loop or reduce function just to get multiple matching ranges, see this example:

And there are still many APIs we only have access to through NSString (and therefore Objective-C), like [replacingOccurrences(of:with:)](https://developer.apple.com/documentation/foundation/nsstring/1412937-replacingoccurrences) which will now get a new [replacing(_:with:)](https://github.com/apple/swift-evolution/blob/main/proposals/0357-regex-string-processing-algorithms.md#replace) Swift-native API.

See this table for a summarizing list of all new APIs getting added to Swift.

On top of these new APIs, the proposal is also adding a ~= operator overload for pattern matching with Regexes + a new [CustomConsumingRegexComponent](https://github.com/apple/swift-evolution/blob/main/proposals/0357-regex-string-processing-algorithms.md#customconsumingregexcomponent) protocolwhich will allow Apple & 3rd party library authors to make their own types directly usable in many of the new APIs + within the Regex builder DSL.

SE-0358: Primary Associated Types in the Standard Library

Links: Proposal Document 📝 | Review 🧵**

This one is a follow-up proposal to SE-0346 (presented in first issue) and basically is about extending the Standard Library with the new primary associated type declarations in order to make SE-0346 actually usable.

See this table for an overview of all the protocols planned to be changed.

Recently Active Pitches/Discussions

Some threads inside the “Evolution” category with activity within the last month I didn’t link yet. I’ll cover them once they become official proposals:

  • Piecemeal adoption of Swift 6 features in Swift 5.x: Discussion 🧵

  • Keypath-based sort/min/max Sequence operations: Discussion 🧵

  • Allow non-optional getters for optional requirements: Discussion 🧵

  • Unicode for String Processing: Draft **📝 | **Discussion 🧵

  • Will string processing efforts also expose Bidi_Class?: Discussion 🧵

  • Approximate equality for floating-point: Discussion 🧵

  • Opaque result types with limited availability: Discussion 🧵

  • Standardise **swift test** across platforms: Discussion 🧵

  • Improving **String.Index**’s printed descriptions: Discussion 🧵

  • **Have all adapters in the std lib expose their ****base**: Discussion 🧵

Other Developments worth Mentioning

The migration of Swift bug reports to GitHub has been completed with more than 12,000 issues of which more than 5,000 are marked as “Open”: See here.

Ted Kremenek, officially representing Apple in the Swift community and Core Team member, posted an update to the same thread where Chris Lattner, the originator of Swift, had posted his reasons to depart from the Swift community (which I had already discussed at the end of the first issue). This shows that their efforts to split the Core team’s responsibilities for improving upon some of the criticized aspects are making progress.

More specifically, he mentions a new language design work group and that “the goal is to make the core team more of a general oversight group”. He specifically mentioned that a documentation tooling workgroup is being discussed, an also mentioned Swift website workgroup was already formed with none other than Paul Hudson and Dave Verwer as members, among others.

On the same note, a Numerical/ML workgroup is being discussed, too. And speaking about workgroups, the Swift Server Workgroup has just posted its annual update.

That’s it from my monthly update!

💁🏻‍♂️ Enjoyed this article? Check out my app RemafoX! A native Mac app that integrates with Xcode to help translate your app. Get it now to save time during development & make localization easy.

]]> Swift Evolution Monthly: April ‘22 https://evolutionkit.dev/blog/swift-evolution-monthly-april-22/ https://evolutionkit.dev/blog/swift-evolution-monthly-april-22/ Thu, 21 Apr 2022 00:00:00 +0000 Swift Evolution Monthly: April ‘22

Wow, this is just the 2nd issue of this newsletter and nearly 300 developers subscribed to it, already! All thanks to Dave and others from the community for spreading the word. Thank you! 🙏

I heard your feedback: You’re right, the first issue was too long. Partly because it was never planned to be released as a newsletter, and partly because it was the first, so I gave a (lengthy) introduction. Despite covering more proposals today, this issue is only ~60% of the length! (2,400 words → 1,500 words)

The two main focus topics on Swift Evolution this past month both sound a bit scary: Regular Expressions and Existentials. But don’t worry: The Regex story can be broken down to “Swift is making them less scary!”. And I didn’t know what an “Existential” was before writing this issue myself — I’ll explain!

Enjoy. 🍻

Accepted Proposals

The following proposals presented in past issues have been accepted:

Also, one more proposal was accepted that I had not mentioned because I found it not relevant to app developers. From now on I’ll mention these kinds of proposals, too, with a short comment on who this might be of interest to. This one mostly concerns those shipping Swift packages to Linux systems:

On to new proposals!

SE-0347: Type inference from default expressions

Links: Proposal Document 📝 | Acceptance Rationale ✅ | Review 🧵

Currently, providing a default value for generic parameters produces an error:

Starting with (probably) Swift 5.7, the above code will compile successfully! Here’s another example of what will be possible with the usage side included:

SE-0348: buildPartialBlock for result builders

Links: Proposal Document 📝 | Review 🧵

This one will only concern you directly if you try writing a DSL using Result Builders. But even as a user of frameworks like SwiftUI or Point-Free’s swift-parsing, you are going to benefit from this indirectly because it significantly reduces the number of overloads the library authors have to write to make things like VStack support multiple subviews.

This should allow Apple to accept more than 10 views in the future, making workarounds like [Group](https://stackoverflow.com/a/58398355) less necessary. Point-Free has already reported that they will be able to increase their parser builder limit from 6 to above 10 and even to infinity for some specific combination of types. Cross-platform SwiftUI implementations such as Tokamak or Swift Cross UI should profit from this, too. It’s also going to allow for new types of builders, such as the new [RegexComponentBuilder](https://github.com/apple/swift-experimental-string-processing/blob/85c7d906dd871364357156126278d9d427936ca4/Sources/_StringProcessing/RegexDSL/Builder.swift#L13) planned for the Regex proposals below.

The feature is already implemented and will ship with Swift 5.7.

SE-0349: Unaligned Loads and Stores from Raw Memory

Links: Proposal Document 📝 | Acceptance Rationale ✅ | Review 🧵

Helps prevent alignment mismatches in low-level byte data parsing by introducing a new loadUnaligned function. Probably ships with Swift 5.7.

Proposals In Review/Revision

For the following proposals, you can still provide feedback. The current rejection rate is less than 10%, so it’s likely they get accepted. Revisions are more common.

SE-0350: Regex Type and Overview

Links: Proposal Document 📝 | Review 🧵

This is a big one. Not necessarily this proposal specifically. But it is kicking off a series of Regex-related proposals that are going to greatly improve how we can process Strings to read/transform specific data from parts of them. To put things in context, this is the start to implement Declarative String Processing in Swift, which itself is part of a larger data processing improvement plan.

But let’s get back to this proposal in particular. It introduces a Regex type:

Furthermore, a ChoiceOf builder would allow specifying multiple variants (replaces A|B) and even a TryCapture {} transform: {} would be available to directly transform a sub-match into an expected type, such as into an enum. Optionally (for A?) and Repeat (for A{n,m}) complete the DSL:

The value variable is of type “any type that conforms to Codable”. First, we use a [String], then a plain String and it compiles successfully. Under the hoods, Swift 5 creates an existential box type for us implicitly and dynamically changes the type of the value stored inside it from [String] to String.

Since Swift 5.6 (thanks to SE-0335) we can (and should!) make this existential more explicit by adding the keyword any in front of Codable:

Starting with Swift 6, the first example will no longer compile and we will need to add any whenever we’re creating an existential type, to make its creation more explicit to developers. This is important because existential types are quite limited in Swift. Some of these limitations come from their type-erasing nature and can’t be fixed, but some can be fixed.

Developers would run into a whole set of compilation errors and had to work around them. But we are going to see improvements in the near future, like with SE-309 shipping with Swift 5.7.

This proposal further improves working with existentials by smoothing out the interaction between them and generics. Calls to generic functions that would have failed with an error like “protocol ‘P’ as a type cannot conform to itself”, will now succeed. Additionally, before this, we could replace a some View parameter with any View, but not the other way around. This proposal would allow us to refactor in the other direction as well.

✨ Want to see your ad here? Contact me at ads@fline.dev to get in touch.

SE-0353: Constrained Existential Types

Links: Proposal Document 📝 | Review 🧵

In the previous issue, we discussed SE-0346 which allows us to specify generic types in place instead of specifying them with a where clause at the end. This proposal aims to bring the same convenience to existential types with the anykeyword:

Recently Active Pitches/Discussions

Here are some pitches/discussions with a recent activity you might find interesting — some of them are a continuation of topics discussed above. Of course, I will cover them in more detail once they become official proposals:

Other Developments worth Mentioning

Apple officially announced the release process for Swift 5.7 on March 29th. Doing the math based on this table in the Swift GitHub repo, a Swift release happens 5–6 months after its announcement on average. So it’s pretty safe to say we’ll be getting Swift 5.7 as part of the Xcode 14 release this autumn, starting with a first beta right after the WWDC22 keynote on June 6th.

In another announcement from March 22nd, Apple laid out a timeline for migrating Swift bug reports over to GitHub from a separate JIRA system that was in use until now. This should help with linking bugs to PRs properly as both the code and the related issues can live in one place. Also reporting bugs should become easier as you can just use your existing GitHub account. At the moment of this writing, the migration is ongoing and we can see a read-only preview of the migrated issues. The migration is planned to be completed by April 28th, then you should see the Issues tab in the Swift repo.

That’s it from this month’s update!

💁🏻‍♂️ Enjoyed this article? Check out my app RemafoX! A native Mac app that integrates with Xcode to help translate your app. Get it now to save time during development & make localization easy.

]]> Swift Evolution Monthly: First Issue https://evolutionkit.dev/blog/swift-evolution-monthly-first-issue/ https://evolutionkit.dev/blog/swift-evolution-monthly-first-issue/ Thu, 17 Mar 2022 00:00:00 +0000 Swift Evolution Monthly: First Issue

Recap of Swift Evolution History

Since the day Apple open-sourced Swift in December 2015 it was possible to follow and even participate in the future of Swift. At the beginning the discussions were hard to explore & a mess to follow due to their mailing list nature. Thankfully, more than a year after the first suggestion to migrate over to a proper forum software and dozens of participators backing the idea, the Core Team had decided to do the migration. It took nearly another year until the Swift Forums officially opened in January 2018.

In the 4 years since then ~17k developers discussed Swift topics in ~27k threads with ~245k posts overall as of March 2022 (source). Even more developers (probably ~100k) have at least viewed and read some portion of them. A whole 9 new Swift versions were released since migrating to the forum, each accompanied by an official announcement blog article which lists all Swift Evolution proposals that went through the Swift Evolution Process and informed the changes: 4.1, 4.2, 5.0, 5.1, 5.2, 5.3, 5.4, 5.5, 5.6.

The road to Swift 6 is outlined since January 2020 and is the most-viewed thread in the forum for a reason. It summarizes the Swift 6 focus in 3 areas:

First, “the Swift software ecosystem” to broaden Swifts usefulness outside of Apple app development. Second, “a fantastic development experience” like faster builds & more accurate error messages. And third, “user-empowering language directions” such as improvements to concurrency, generics, DSLs, memory-ownership and low-level programming. All these areas have seen large steps forward since the announcement with the changes in Swift 5.2 and later, Swift Concurrency being a large recent focus. But there’s still much work to be done in all of them, so Swift 6 release is not a topic for this year and we can expect at least Swift 5.7 and 5.8 before that.

Why a “Swift Evolution Monthly”?

My main takeaway from the recap of the Swift Evolution history above is that the future development of Swift is truly a community effort. While Apple is still the main driver of this language (more on that at the end), setting the rough direction and current focus, we all have a say in all the details and can even make suggestions for improvements or entirely new features ourselves.

At the same time, we developers are “users” of the Swift language first and foremost. Being a “designer” of a language is an entirely different thing and can eat quite a large chunk of our precious time. Nevertheless, I’m personally very interested in what’s coming next in Swift so I can make informed decisions about which APIs or frameworks I make use of right now. And on which parts I maybe use a temporary solution and wait a couple of months before diving into making things proper. Because there might be a related Swift feature coming soon that will simplify things or allows entirely new concepts. But how would I know if I didn’t follow the discussions? And will the change actually work for my problem, too, or should I give feedback?

For these reasons, I sometimes wander around in the Pitches category to find ideas I want to support. But more importantly, I’m skimming through the Proposals that are officially in review or even accepted. Of course, I’m reading Paul Hudson great write-ups whenever a new Swift version is released, but for an informed long-term decision-making that’s too late for me.

Actually, Paul Hudson used to talk about new and coming Swift features together with Erica Sadun in the Swift over Coffee podcast. Likewise, Jesse Squires and JP Simard used to talk about Swift Evolution proposals in their Swift Unwrapped podcast. But both stopped recording new episodes after their WWDC episodes in 2020 and 2021, respectively.

The same Jesse Squires had also started the Swift Weekly Brief newsletter in 2015 right after Swift was open-sourced, to stay up-to-date with the latest in Swift Evolution. The community-driven newsletter was later maintained by Bas Broek and most recently by Kristaps Krinbergs. But unfortunately, it ended a few months ago with Issue #200 on December, 16th 2021.

So, here we are, me trying to fill the gap with a monthly summary of what interesting developments I’ve come across in the Swift forums.

ℹ️ The following list is just a selection of proposals I think are interesting to app developers. For a full list, see 🌐this website.info

Accepted Proposals

SE-0329: Clock, Instant, and Duration

Problem:
We have many different types to measure & do calculations with continuous time: Date, TimeInterval, DispatchTime, DispatchTimeInterval, …
Currently, there’s no unified concept of time in all frameworks. Also, TimeInterval is technically just a typealias for Double and is implicitly respresenting time in the unit of “seconds”. There’s no explicitness to the unit, nor are there any APIs available to convert easily between units (like here). Also, as a floating-type, TimeInterval is susceptible to rounding errors.

Solution:
Three new types will be introduced to unify the concepts of time in Swift:

public struct Duration {
  public var components: (seconds: Int64, attoseconds: Int64)
}

Duration prevents any inexact rounding errors like with Double by storing the time interval in two Int64 variables: seconds and attoseconds. But this internal representation will probably never be accessed directly, as many convenience extensions are provided, such as a static .seconds method to write readable code like let duration: Duration = .seconds(5). Duration also supports arithmetic operations such as +, — or * and /.

public protocol InstantProtocol {
  func advanced(by duration: Duration) -> Self
  func duration(to other: Self) -> Duration
}

Types adhering to the InstantProtocol, such as Date in the future, basically represent an instant in time and have APIs to interact with the Duration type. Dates addingTimeInterval() method gets unified to advanced(by:) and timeIntervalSince() method gets unified to duration(to:). Types adhering to InstantProtocol will also support the arithmetic operations + and -.

public protocol Clock {
  associatedtype Instant: InstantProtocol
  
  var now: Instant { get }
  func sleep(until deadline: Instant, tolerance: Instant.Duration?) async throws 
}

extension Clock {
  func measure(_ work: () async throws -> Void) reasync rethrows -> Instant.Duration
}

Lastly, types adhering to the Clock protocol, like a new UTCClock type in Foundation in the future, will provide a way to get the current time instant via a static .now computed property (so UTCClock.now will be equal to Date()). Also, they will provide an asynchronous sleep(until:tolerance:) function. An extra convenience function measure(work:) -> Duration will help stopping the time of executing a chunk of code — neat! The Clock protocol will also make it easier to create a custom type for controlling time in tests.

Expected in: ~Swift 5.7 (my guess based on merged PR from Feb 16th)

SE-0339: Module Aliasing For Disambiguation

Problem:
In SwiftPM, when including two dependencies that both had a target named Utils for example, currently we would get a name collision error. To solve this, we would need to edit one of the dependencies (e.g. by forking) and rename the Utils target in one to something else, like GameUtils.

Solution:
Instead of editing the dependency, we will be able to just provide an alias name to a specific packages dependency right in our projects Package.swift manifest file by using the new moduleAliases parameter like so:

.target(
  name: "App",
  dependencies: [
    .product(name: "Game", moduleAliases: ["Utils": "GameUtils"], package: "swift-game"), 
    .product(name: "Utils", package: "swift-draw"), 
  ]
)

Expected in: ~Swift 5.7 (my guess based on merged PR from Feb 9th)

SE-0341: Opaque Parameter Declarations

Problem:
Today, we can just return some View from functions instead of having to specify a generic type <T: View>. This kind of return type with the some keyword is called an “opaque type” (see SE-0244). It saves us boilerplate code. If you’re like me, you might have tried to specify some View in parameters of functions as well, when trying to extract some SwiftUI code from a body that got too long. But it doesn’t currently compile…

Solution:
In the future it will compile! For example, instead of writing this:

func horizontal<V1: View, V2: View>(_ v1: V1, _ v2: V2) -> some View {
  HStack {
    v1
    v2
  }
}

You’ll be able to write this (note that no generic types are needed):

func horizontal(_ v1: some View, _ v2: some View) -> some View {
  HStack {
    v1
    v2
  }
}

Expected in: Swift 5.7 (confirmed in ‘Status’ field)

Proposals In Review

ℹ️ Note that for the following proposals you can still provide feedback (by clicking the “Review” link in the proposal). Also changes are possible. And in rare cases (<10%), they might even get rejected.

SE-0344: Distributed Actor Runtime

Problem:
This is a large one — so large it even has a Table of Contents! — and I don’t fully understand it yet myself. But together with SE-0336 Distributed Actor Isolation, which was accepted back in January, it seems this is one of the more amazing and unique features Swift will provide compared to other modern languages.

The problem, as far as I understand, is that the newly introduced actor type provides safety only on a localenvironment level, as in “safety for access between different threads on the same process of one machine”. (If you’re new to actors in general, Paul Hudson has a great write-up on that, too.) An actor type does not provide safety in accessing data between different processes or even different machines though. This makes writing correct code accessing the same data across machines hard, for example in client-server situations or in live peer-to-peer communication.

Solution:
Besides the new distributed actor type and DistributedActor protocol accepted in SE-0336, a new DistributedActorSystem protocol is introduced here which basically defines details about how communication between different environments happens. If I understand it correctly, different implementations for different purposes can be provided, such as one for cross-process communication, one for clustering and another for client-server communication. In the end, we would be able to define a function as being distributed much like we can now define functions to be async like so:

distributed actor Game {
  var state: GameState = ...

  // players can be located on different nodes
  var players: Set<Player> = []

  distributed func playerJoined(_ player: Player) {
    others.append(player)
    if others.count >= 2 { // we need 2 other players to start a game
      Task { try await self.start() }
    }
  }

  func start() async throws { ... }
}

Then all calls into such functions need to be awaited for like here:

await game.playerJoined(newPlayer)

So the overall goal of this is to make distributed environment access to data (nearly) as simple as thread-safe access to data has become with actors. Does this hold the potential to even eliminate all our client-server networking code in our apps, provided that the server is implemented in Swift, too? I have no idea. And from what I hear, that’s not the main goal here. But it sounds like a very interesting area to keep an eye on in the coming years ahead for sure!

Expected in: Swift 5.8 or later (partially implemented, feature flag on main)

SE-0345: [if let](https://github.com/apple/swift-evolution/blob/main/proposals/0345-if-let-shorthand.md) shorthand for shadowing an existing optional variable

Problem:
Optional binding as in if let foo = foo { … } is extremely common in Swift code. Repeating the same identifier twice is verbose and can lead to weird indentation situations when line limits are reached with long variable names. Solving this verbosity was already requested back in 2015 by the community, shortly after Swift had been open sourced.

Solution:
Instead of repeating the variable name like in this code:

let someLengthyVariableName: Foo? = ...
let anotherImportantVariable: Bar? = ...

if let someLengthyVariableName = someLengthyVariableName, let anotherImportantVariable = anotherImportantVariable {
    ...
}

We would be able to get rid of the right = repeatingVariableName part like so:

let someLengthyVariableName: Foo? = ...
let anotherImportantVariable: Bar? = ...

if let someLengthyVariableName, let anotherImportantVariable {
    ...
}

Expected in: ~Swift 5.7 (small PR 👍, but Review feedback is quite mixed)

SE-0346: Lightweight same-type requirements for primary associated types

Problem:
Have you ever written a function for a concrete type, like for Array:

func concatenate(_ lhs: Array<String>, _ rhs: Array<String>) -> Array<String> {
  ...
}

And then later you wanted to generalize it over all types conforming to Sequence to also make it work with Set, Dictionary and more like this:

func concatenate<S : Sequence>(_ lhs: S, _ rhs: S) -> S where S.Element == String {
  ...
}

You find it weird that we specify the where clause at the end? And you find it cumbersome to lookup the name of the associatedtype (here Element) within the implementation of the Sequence protocol? These and other annoyances around generics exist at the moment, see also this forum thread.

Solution:
Consistent to how we write generic type requirements for concrete types like Array<String>, we would be able to specify the associated type right in-place:

func concatenate<S : Sequence<String>>(_ lhs: S, _ rhs: S) -> S {
  ...
}

We could emit the where in more places, all these pairs would be equivalent:

// Extensions
extension Collection where Element == String { ... }
extension Collection<String> { ... }

// Inheritance
protocol TextBuffer : Collection where Element == String { ... }
protocol TextBuffer : Collection<String> { ... }

// Nested Opaque Parameters
func sort<C : Collection, E : Equatable>(elements: inout C) {} where C.Element == E
func sort(elements: inout some Collection<some Equatable>) {}

Expected in: Swift 5.7 or later (partially implemented, feature flag on main)

✨ Want to see your ad here? Contact me at ads@fline.dev to get in touch.

Other Developments worth Mentioning

Did you know that Chris Lattner, the original author of Swift, has decided to leave the Swift core team and even the Swift Evolution community? If you haven’t come across this news already, I recommend reading his detailed post on the reasons why he’s leaving, which is a unique chance to get some detailed insights in how Swift has been developed in the past.

Just a few chosen (negative) quotes from his post:

… the core team is a toxic environment in the meetings themselves.

… after being insulted and yelled at over WebEx (not for the first time, and not just one core team member) …

… a complicated situation and many pressures (including lofty goals, fixed schedules, deep bug queues to clear, internal folks that want to review/design things before the public has access to them, …)

But he does end on a positive note, which I totally agree with:

I think that Swift is a phenomenal language and has a long and successful future ahead …

I think that a healthy and inclusive community will continue to benefit the design and evolution of Swift.

I personally am very thankful for all Chris has done for our community and wish him all the best for his future! It’s worth mentioning that there were some deeper structural changes to the Swift core team announced already that might help improve the situation. As for the struggles he seemed to have had, it’s hard to comment on them without further details.

Knowing nothing about Apples internal plans and the discussions of the core team, I am still optimistic about the community aspect of Swift in the years to come. While Apple is still far away from being a transparent company, from my experience they are trying to open up more and more recently on developer topics. For example, they open sourced DocC last year at WWDC. They also open sourced the Markdown parser they use in SwiftUI. And just this week, they even open sourced the swift.org website itself. So things are going in the right direction. Sometimes it might feel like two steps forward, one step back. But even that is still a step forward overall!

I’m looking forward to what else the future holds for us Swift developers. A lot is going on for sure. And I hope that this article helped you explore some of it. Follow me if you don’t want to miss future Swift Evolution Monthly posts.

💁🏻‍♂️ Enjoyed this article? Check out my app RemafoX! A native Mac app that integrates with Xcode to help translate your app. Get it now to save time during development & make localization easy.

]]>