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

Adoption of Swift 6 features #310

Open
3 tasks
rebello95 opened this issue Oct 14, 2024 · 0 comments
Open
3 tasks

Adoption of Swift 6 features #310

rebello95 opened this issue Oct 14, 2024 · 0 comments

Comments

@rebello95
Copy link
Collaborator

I'm opening an issue to track some low-hanging fruit with regard to Swift 6 features that we should explore in Connect-Swift:

  • Enforcing strict concurrency: I believe all these warnings were fixed with Add more Sendable conformances to resolve warnings #309, but we should switch the toolchain to Swift 6 to enforce this
  • Typed throws: Would it make sense to add throws(ConnectError) in some places?
  • Utilize package visibility: The files in this directory are commented as internal-only but are public so they can be consumed by ConnectNIO. We can make these package instead once running on the updated toolchain to remove these from the public interface

We are currently blocked on fully adopting Swift 6 by apple/swift-protobuf#1729.

rebello95 added a commit that referenced this issue Oct 17, 2024
This PR adds deprecation warnings to APIs that are considered
package-internal but cannot yet be marked as `package` instead of
`public` until we adopt Swift 6 (see
#310). We can't make
these APIs _currently_ deprecated since that will introduce deprecation
warnings where they're used within the library, but we can at least add
_future deprecation_ warnings which will show up in the IDE as shown
below:

<img width="684" alt="Screenshot 2024-10-16 at 11 27 45 AM"
src="https://github.com/user-attachments/assets/be489f7f-bf32-466d-8aa3-1fc999bba0c6">

The goal of doing this is to help enable us to tag a 1.0 before adopting
Swift 6 so we can mark those APIs as `package` afterwards and reasonably
consider it a non-breaking change.

---------

Signed-off-by: Michael Rebello <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant