[swift-users] Handle deprecated enum cases from a library

[Dennis Weissmann]

Hi Charles,

You are right (the `default` case would not catch the deprecated values but only new ones introduced in future releases), but the compiler doesn’t seem to know that :(

But now that you say it, one approach could be to pattern match the raw values (and, well, have a default clause, which I really want to avoid) 🤔

- Dennis

Sent from my iPhone

>> On 4. Nov 2017, at 10:42 PM, Charles Srstka <cocoadev at charlessoft.com> wrote:
>> 
>> On Nov 4, 2017, at 9:38 AM, Dennis Weissmann via swift-users <swift-users at swift.org> wrote:
>> 
>> Hi swift-users,
>> 
>> In a project (iOS 11 only) we use Touch ID for authentication and handle errors like so:
>> 
>> private func handleLocalAuthenticationError(_ error: LAError) {
>>     switch error.code {
>>     case .userCancel, .appCancel, .systemCancel:
>>         // Handle cancelation
>>     case .authenticationFailed:
>>         // Handle failure
>>     case .passcodeNotSet:
>>         // Handle passcode absence
>>     case .touchIDNotEnrolled:
>>         // Handle no Touch ID enrollment
>>     case .touchIDNotAvailable:
>>         // Handle no Touch ID availabe
>>     case .touchIDLockout:
>>         // Handle Touch ID Lockout
>>     case .userFallback:
>>         // Handle user fallback
>>     case .invalidContext:
>>         // Handle failure with invalid context
>>     case .notInteractive:
>>         // Handle no interaction allowed error
>>     }
>> }
>> 
>> This worked fine until recently, when with the release of iOS 11 and the introduction of Face ID, `.touchIDLockout`, `.touchIDNotEnrolled` and `.touchIDNotAvailable` were deprecated in favor of the newly introduced `.biometryLockout`, `.biometryNotEnrolled` and `.biometryNotAvailable`.
>> 
>> When we link against the latest SDK we need to add those in order to compile (which is obviously good).
>> 
>> Now when we add those cases, the compiler shows the following warnings:
>> 
>> <unknown>:0: warning: 'touchIDLockout' was deprecated in iOS 11.0: use LAErrorBiometryLockout
>> <unknown>:0: warning: 'touchIDNotEnrolled' was deprecated in iOS 11.0: use LAErrorBiometryNotEnrolled
>> <unknown>:0: warning: 'touchIDNotAvailable' was deprecated in iOS 11.0: use LAErrorBiometryNotAvailable
>> 
>> The problem here is, that we can't remove the old ones and replace them with their new variants because for Swift the enum is then not exhaustive (which also makes sense, they're only deprecated, not removed after all).
>> 
>> Even though not optimal (read "really bad because not exhaustive") I thought about removing the old cases and adding a default label:
>> 
>> private func handleLocalAuthenticationError(_ error: LAError) {
>>     switch error.code {
>>     case .userCancel, .appCancel, .systemCancel:
>>         // Handle cancelation
>>     case .authenticationFailed:
>>         // Handle failure
>>     case .passcodeNotSet:
>>         // Handle passcode absence
>>     case .biometryNotEnrolled:
>>         // Handle no biometry enrollment
>>     case .biometryNotAvailable:
>>         // Handle no biometry availabe
>>     case .biometryLockout:
>>         // Handle biometry Lockout
>>     case .userFallback:
>>         // Handle user fallback
>>     case .invalidContext:
>>         // Handle failure with invalid context
>>     case .notInteractive:
>>         // Handle no interaction allowed error
>>     default:
>>         // hopefully only deprecated cases
>>         break
>>     }
>> }
>> 
>> However, in this case the compiler warns that "Default will never be executed".
>> 
>> Is there any way of getting rid of these warnings (preferably the first 3 so that we don't have to have default clause)?
>> 
>> Thanks!
>> 
>> - Dennis 
>> _______________________________________________
>> swift-users mailing list
>> swift-users at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-users
> 
> Hi Dennis,
> 
> .touchIDLockout, .touchIDNotAvailable, and .touchIDNotEnrolled have the same rawValue as .biometryLockout, .biometryNotAvailable, and .biometryNotEnrolled. So if you handle the latter, it’ll also handle the former.
> 
> Charles
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-users/attachments/20171105/70f47399/attachment.html>