Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement the benefits of switching to Swift 6 #56

Closed
2 of 4 tasks
lawrence-forooghian opened this issue Sep 18, 2024 · 1 comment
Closed
2 of 4 tasks

Implement the benefits of switching to Swift 6 #56

lawrence-forooghian opened this issue Sep 18, 2024 · 1 comment
Assignees
Labels
code-quality Affects the developer experience when working in our codebase.

Comments

@lawrence-forooghian
Copy link
Collaborator

lawrence-forooghian commented Sep 18, 2024

Requires #21 first.

┆Issue is synchronized with this Jira Task by Unito

@lawrence-forooghian lawrence-forooghian added the code-quality Affects the developer experience when working in our codebase. label Sep 18, 2024
lawrence-forooghian added a commit that referenced this issue Sep 18, 2024
This means:

- using it for development (which will allow us to use Swift Testing,
  which we’ll do in #55)

- requiring users of the library to use it (so that we can use Swift 6
  features, which we’ll do in #56) — we’ve decided we’re happy to do
  this since from April 2025 Apple will force users wishing to upload to
  the App Store to use it anyway

Whilst implementing this, I decided to revisit my comment from
646c220:

> I haven’t committed the `.swiftpm/configuration/Package.resolved` file
> created by Xcode 16. We already have two Package.resolved files (see the
> `comparePackageLockfiles` lint task) and so let’s wait for Xcode 16 to
> be released to see whether this file is going to stick around (perhaps
> it will become part of the .gitignore created by the SPM that ships with
> Xcode 16).

With the release version of Xcode 16, I am no longer able to get Xcode
to generate this file, so either they changed something or it’s going to
reappear at some point when we poke Xcode in some very specific way (at
which point we can decide what to do with it).

Resolves #21.
@lawrence-forooghian lawrence-forooghian self-assigned this Sep 18, 2024
lawrence-forooghian added a commit that referenced this issue Sep 18, 2024
This means:

- using it for development (which will allow us to use Swift Testing,
  which we’ll do in #55)

- requiring users of the library to use it (so that we can use Swift 6
  features, which we’ll do in #56) — we’ve decided we’re happy to do
  this since from April 2025 Apple will force users wishing to upload to
  the App Store to use it anyway

Whilst implementing this, I decided to revisit my comment from
646c220:

> I haven’t committed the `.swiftpm/configuration/Package.resolved` file
> created by Xcode 16. We already have two Package.resolved files (see the
> `comparePackageLockfiles` lint task) and so let’s wait for Xcode 16 to
> be released to see whether this file is going to stick around (perhaps
> it will become part of the .gitignore created by the SPM that ships with
> Xcode 16).

With the release version of Xcode 16, I am no longer able to get Xcode
to generate this file, so either they changed something or it’s going to
reappear at some point when we poke Xcode in some very specific way (at
which point we can decide what to do with it).

Resolves #21.
@lawrence-forooghian
Copy link
Collaborator Author

Hmm, I have a feeling that we aren’t going to be able to implement the AsyncSequence improvements given above; it seems like:

  • using AsyncSequence with primary associated types requires macOS 15 etc (gives the error 'Failure' is only available in macOS 15.0 or newer)
  • specifying that an AsyncSequence is unable to throw (e.g. by writing associatedtype Subscription: AsyncSequence where Subscription.Element == PresenceEvent, Subscription.Failure == Never) gives the same error.

So, I think I’ll close this issue, and update the comments in the code that relate to this improvement. Maybe I’m wrong and there is something that we can improve, but it's not obvious to me at the moment 🤷

lawrence-forooghian added a commit that referenced this issue Sep 24, 2024
We can’t implement some of the #56 improvements that I hoped Swift 6
would enable, due to them requiring OS support.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
code-quality Affects the developer experience when working in our codebase.
Projects
None yet
Development

No branches or pull requests

1 participant