-
Notifications
You must be signed in to change notification settings - Fork 218
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
Make core types Sendable and @unchecked Sendable #308
Conversation
@@ -25,8 +25,8 @@ import Foundation | |||
/// Reads and writes keychain elements that are stored on the Secure Enclave using Accessibility attribute `.whenPasscodeSetThisDeviceOnly`. The first access of these keychain elements will require the user to confirm their presence via Touch ID, Face ID, or passcode entry. If no passcode is set on the device, accessing the keychain via a `SinglePromptSecureEnclaveValet` will fail. Data is removed from the Secure Enclave when the user removes a passcode from the device. | |||
@objc(VALSinglePromptSecureEnclaveValet) | |||
@available(watchOS 3, *) | |||
public final class SinglePromptSecureEnclaveValet: NSObject { | |||
|
|||
public final class SinglePromptSecureEnclaveValet: NSObject, @unchecked Sendable { |
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.
The localization context is a var
on the type. It's only mutated within a lock, so we are indeed sendable. But the compiler won't be convinced of that... so we use unchecked.
private var baseKeychainQuery: [String : AnyHashable] { | ||
return service.generateBaseQuery() | ||
} |
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.
I don't love this, but AnyHashable
isn't Sendable
and service.generateBaseQuery()
is fast, so in the tug-of-war between "have the compiler check the thing I know is safe" and "we know it's safe so opt out of checking to do something faster" I'm leaning towards the former.
I generally lean towards calling dropped Xcode support a breaking change, but the "haven't been able to ship to the App Store with these versions for years" is an interesting mitigating factor. I'm okay with dropping that as a minor version bump. 👍 |
We've been thread-safe since v1. We just hadn't told the compiler this fact yet.
This PR won't compile on Xcode 12.4 or prior, and we currently support back to Xcode 11. We therefore have two options:
I'd be curious to hear from @pwesten and friends how they'd like to approach this before I go and update the README on this PR.