Update TransactionState.swift - build fix for Xcode 26 toolchain #194
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
As Xcode 26 has stricter type inference, the body closure needs to be re-wrapped in another closure to ensure type inference. Tested on Xcode 26 beta 2.
|
@majda107 Hi, I'm not owner of this repository but could you try it again with latest release/6.2 toolchain? I tried it on the https://www.swift.org/install/macos/
actually this was not a new behavior of type inference, but a bug of the swift compiler. Since the fix has been merged a few weeks ago, the fix should be included in the latest 6.2 toolchain. ref: |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Pull Request Type
Description
As the new Xcode 26 uses a newer toolchain, it introduces stricter type inference that cannot be disabled (this stricter inference applies to both Swift 5 and Swift 6, and to my knowledge, cannot be bypassed using any compiler flag).
This stricter behavior causes a severe build error for which I couldn’t find any compilation workaround. For reference, I have tried several compilation flags and custom Swiftly toolchains, but the issue lies somewhere deep in the Xcode 26 built-in toolchain.
The fix has been tested on Xcode 26 beta 2 and will most likely be required for the upcoming stable release as well.
Motivation
The motivation for this fix was to ensure that projects written in Swift 5 / Swift 6, which currently build successfully in Xcode 18, also build cleanly in newer versions of Xcode 26.
Please take a look and consider merging this fix — or suggest an alternative solution — as soon as possible, since many users will likely want to use the library with Xcode 26.
Issue, fix, and the impact on existing code
The issue lies in assigning the
bodyclosure to a member with a slightly different type. The fix wraps thebodyclosure in another closure that calls the original, ensuring proper type alignment.This change should not have any significant effect on the existing code. However, please verify this — especially if the change interacts with the @mainactor annotation in a non-obvious way.
I'm not entirely sure if this is the best way to resolve the issue — it may be possible to adjust the member's type instead. However, as I'm not deeply familiar with the project's domain, I'm leaving that decision to the author.
Personally, I believe this closure assignment was more likely an oversight or leftover code that happened to compile due to the more permissive type inference in the Xcode 18 (or earlier) toolchain, rather than a deliberate design choice.