-
Notifications
You must be signed in to change notification settings - Fork 1
Swift 6 strict concurrency support #17
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
base: main
Are you sure you want to change the base?
Conversation
Also remove unneeded AudioObjectPropertyAddress: Hashable
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
Adds strict concurrency support by marking AudioObject
and its subclasses as @unchecked Sendable
, and updates the property change notification block to be @Sendable
.
- Introduces
@unchecked Sendable
conformance toAudioObject
base class and all subclasses - Updates
PropertyChangeNotificationBlock
alias to@Sendable
- Bumps copyright year in
AudioEndpoint.swift
Reviewed Changes
Copilot reviewed 21 out of 21 changed files in this pull request and generated no comments.
File | Description |
---|---|
AudioObject.swift | Added @unchecked Sendable to AudioObject and made its notification block @Sendable |
AudioControl.swift and other subclasses | Added redundant @unchecked Sendable conformance to each subclass of AudioObject |
AudioEndpoint.swift | Updated copyright years |
Comments suppressed due to low confidence (3)
Sources/CAAudioHardware/AudioObject.swift:12
- [nitpick] Add a brief doc comment explaining why
AudioObject
is marked@unchecked Sendable
(e.g., underlying C API assumptions) to clarify the concurrency guarantee for future maintainers.
public class AudioObject: Equatable, Hashable, @unchecked Sendable, CustomDebugStringConvertible {
Sources/CAAudioHardware/AudioObject.swift:85
- Consider adding unit or integration tests that exercise
PropertyChangeNotificationBlock
under concurrent usage to verify the notification closure behaves correctly across threads.
public typealias PropertyChangeNotificationBlock = @Sendable (_ changes: [PropertyAddress]) -> Void
Sources/CAAudioHardware/AudioControl.swift:15
- [nitpick] Since
AudioControl
inherits fromAudioObject
which is already declared@unchecked Sendable
, you can remove the redundant@unchecked Sendable
conformance here to reduce duplication.
public class AudioControl: AudioObject, @unchecked Sendable {
The thread-safety of the various
AudioObject
APIs isn't clear. Lacking documentation to the contrary I assume they aren't thread-safe, which means that the current design forAudioSystemObject
needs to be revisited.