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

[Charles Srstka via swift-users]

> On Nov 6, 2017, at 5:47 AM, Dennis Weissmann  
> wrote:
> 
> Hey Charles,
> 
> Thanks for going through this with me :)
> 
> I'm not sure whether or not this is a compiler bug (that's partially why I 
> posted it here), although I have the feeling that *something* is definitely 
> wrong.
> 
> Funnily enough, the following code shows 3 compiler warnings which are 
> incorrect:
> 
> private func handleLocalAuthenticationError(_ error: LAError) {
> switch error.code {
> case .userCancel, .appCancel, .systemCancel:
> print(".userCancel, .appCancel, .systemCancel")
> case .authenticationFailed:
> print(".authenticationFailed")
> case .passcodeNotSet:
> print(".passcodeNotSet")
> case .biometryNotEnrolled, .touchIDNotEnrolled: // Compiler: 
> Case will never be executed
> print(".biometryNotEnrolled, .touchIDNotEnrolled")
> case .biometryNotAvailable, .touchIDNotAvailable:   // Compiler: 
> Case will never be executed
> print(".biometryNotAvailable, .touchIDNotAvailable")
> case .biometryLockout, .touchIDLockout: // Compiler: 
> Case will never be executed
> print(".biometryLockout, .touchIDLockout")
> case .userFallback:
> print(".userFallback")
> case .invalidContext:
> print(".invalidContext")
> case .notInteractive:
> print(".notInteractive")
> }
> }
> 
> let error = LAError(.touchIDLockout)
> handleLocalAuthenticationError(error)
> 
> When you run it in a playground, you can see that the case *gets* executed.
> 
> - Dennis

I’d say that this sort of damned-if-you-do-damned-if-you-don’t behavior that 
emits a warning no matter what you do has to be a compiler bug. Post it on 
bugs.swift.org  and hopefully it will get fixed.

Charles

___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

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

[Dennis Weissmann via swift-users]

Hey Charles,

Thanks for going through this with me :)

I'm not sure whether or not this is a compiler bug (that's partially why I 
posted it here), although I have the feeling that *something* is definitely 
wrong.

Funnily enough, the following code shows 3 compiler warnings which are 
incorrect:

private func handleLocalAuthenticationError(_ error: LAError) {
switch error.code {
case .userCancel, .appCancel, .systemCancel:
print(".userCancel, .appCancel, .systemCancel")
case .authenticationFailed:
print(".authenticationFailed")
case .passcodeNotSet:
print(".passcodeNotSet")
case .biometryNotEnrolled, .touchIDNotEnrolled: // Compiler: 
Case will never be executed
print(".biometryNotEnrolled, .touchIDNotEnrolled")
case .biometryNotAvailable, .touchIDNotAvailable:   // Compiler: 
Case will never be executed
print(".biometryNotAvailable, .touchIDNotAvailable")
case .biometryLockout, .touchIDLockout: // Compiler: 
Case will never be executed
print(".biometryLockout, .touchIDLockout")
case .userFallback:
print(".userFallback")
case .invalidContext:
print(".invalidContext")
case .notInteractive:
print(".notInteractive")
}
}

let error = LAError(.touchIDLockout)
handleLocalAuthenticationError(error)

When you run it in a playground, you can see that the case *gets* executed.

- Dennis

> On Nov 5, 2017, at 7:13 PM, Charles Srstka  wrote:
> 
>> On Nov 5, 2017, at 10:39 AM, Dennis Weissmann > > wrote:
>> 
>>> You can delete the default case here, and your switch will still be 
>>> exhaustive
>> That's exactly my problem! It is *not*.
>> 
>> When I delete the default clause, the compiler warns that the switch is not 
>> exhaustive and fixits suggest to add the "missing" deprecated cases.
>> 
>> - Dennis
> 
> Hi Dennis,
> 
> Ah, I see—although the switch should be considered exhaustive since you have 
> covered all the possible cases, the compiler is claiming that it is not. I 
> would probably consider this to be a compiler bug. Have you considered filing 
> a report at bugs.swift.org ?
> 
> Charles
> 

___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

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

[Charles Srstka via swift-users]

> On Nov 5, 2017, at 10:39 AM, Dennis Weissmann  
> wrote:
> 
>> You can delete the default case here, and your switch will still be 
>> exhaustive
> That's exactly my problem! It is *not*.
> 
> When I delete the default clause, the compiler warns that the switch is not 
> exhaustive and fixits suggest to add the "missing" deprecated cases.
> 
> - Dennis

Hi Dennis,

Ah, I see—although the switch should be considered exhaustive since you have 
covered all the possible cases, the compiler is claiming that it is not. I 
would probably consider this to be a compiler bug. Have you considered filing a 
report at bugs.swift.org ?

Charles

___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

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

[Dennis Weissmann via swift-users]

> You can delete the default case here, and your switch will still be exhaustive
That's exactly my problem! It is *not*.

When I delete the default clause, the compiler warns that the switch is not 
exhaustive and fixits suggest to add the "missing" deprecated cases.

- Dennis

> On Nov 5, 2017, at 4:36 PM, Charles Srstka  wrote:
> 
>> On Nov 5, 2017, at 9:27 AM, Dennis Weissmann > > wrote:
>> 
>> Hi Charles,
>> 
>> I do believe you :)
>> 
>> The problem is that this doesn't work without a compiler warning if you 
>> switch over every case except for the deprecated ones because then the 
>> compiler warns that "default will never be executed".
>> 
>> As per my first mail feel free to try this out in a playground:
>> 
>> 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: // <- Here the compiler 
>> emits a warning that the default will never be executed.
>> // hopefully only deprecated cases
>> break
>> }
>> }
>> 
>> - Dennis
> 
> Hi Dennis,
> 
> The compiler warning is correct. That default *will* never be executed, 
> because if one of the .touchID cases comes up, control flow will go to the 
> .biometry cases.
> 
> Although it’s bridged to Swift, LAError is a C enum, which is just an 
> integer. So if the framework set it to .biometryNotAvailable, it’s -6. If the 
> framework code spelled it .touchIDNotAvailable, it’s still -6. And C has no 
> way to distinguish between the two; -6 is -6. So your .biometryNotAvailable 
> case will catch it either way. You can delete the default case here, and your 
> switch will still be exhaustive (unless Apple adds additional cases to the 
> enum in the future, of course).
> 
> Charles

___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

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

[Charles Srstka via swift-users]

> On Nov 5, 2017, at 9:27 AM, Dennis Weissmann  
> wrote:
> 
> Hi Charles,
> 
> I do believe you :)
> 
> The problem is that this doesn't work without a compiler warning if you 
> switch over every case except for the deprecated ones because then the 
> compiler warns that "default will never be executed".
> 
> As per my first mail feel free to try this out in a playground:
> 
> 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: // <- Here the compiler 
> emits a warning that the default will never be executed.
> // hopefully only deprecated cases
> break
> }
> }
> 
> - Dennis

Hi Dennis,

The compiler warning is correct. That default *will* never be executed, because 
if one of the .touchID cases comes up, control flow will go to the .biometry 
cases.

Although it’s bridged to Swift, LAError is a C enum, which is just an integer. 
So if the framework set it to .biometryNotAvailable, it’s -6. If the framework 
code spelled it .touchIDNotAvailable, it’s still -6. And C has no way to 
distinguish between the two; -6 is -6. So your .biometryNotAvailable case will 
catch it either way. You can delete the default case here, and your switch will 
still be exhaustive (unless Apple adds additional cases to the enum in the 
future, of course).

Charles

___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

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

[Dennis Weissmann via swift-users]

Hi Charles,

I do believe you :)

The problem is that this doesn't work without a compiler warning if you switch 
over every case except for the deprecated ones because then the compiler warns 
that "default will never be executed".

As per my first mail feel free to try this out in a playground:

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: // <- Here the compiler emits 
a warning that the default will never be executed.
// hopefully only deprecated cases
break
}
}

- Dennis

> On Nov 5, 2017, at 4:13 PM, Charles Srstka  wrote:
> 
>> On Nov 5, 2017, at 3:14 AM, Dennis Weissmann  
>> wrote:
>> 
>> 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
> 
> Hi Dennis,
> 
> What I am saying is that the new cases have the same raw values as the old 
> ones. touchIDNotAvailable is -6; biometryNotAvailable is -6. 
> touchIDNotEnrolled is -7; biometryNotEnrolled is -7. touchIDLockout it -8; 
> biometryLockout is -8. They’re just aliases to each other, so if you handle 
> one, you don’t have to handle the other. You can literally ignore the 
> deprecated values and treat them as if they don’t exist. Try this code for 
> yourself if you don’t believe me:
> 
> let err = LAError.touchIDLockout
> 
> switch err {
> case LAError.biometryLockout:
>   print("biometry lockout")
> default:
>   print("default")
> }
> 
> This prints “biometry lockout”.
> 
> Charles
> 

___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

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

[Charles Srstka via swift-users]

> On Nov 5, 2017, at 3:14 AM, Dennis Weissmann  
> wrote:
> 
> 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

Hi Dennis,

What I am saying is that the new cases have the same raw values as the old 
ones. touchIDNotAvailable is -6; biometryNotAvailable is -6. touchIDNotEnrolled 
is -7; biometryNotEnrolled is -7. touchIDLockout it -8; biometryLockout is -8. 
They’re just aliases to each other, so if you handle one, you don’t have to 
handle the other. You can literally ignore the deprecated values and treat them 
as if they don’t exist. Try this code for yourself if you don’t believe me:

let err = LAError.touchIDLockout

switch err {
case LAError.biometryLockout:
print("biometry lockout")
default:
print("default")
}

This prints “biometry lockout”.

Charles

___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

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

[somu subscribe via swift-users]

Also noticed that when Xcode prompts to fill the missing case statements, it 
fills it with the deprecated TouchID case statements (in an iOS 11 project).


> On 5 Nov 2017, at 5:14 PM, Dennis Weissmann via swift-users 
>  wrote:
> 
> 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  > wrote:
> 
>>> On Nov 4, 2017, at 9:38 AM, Dennis Weissmann via swift-users 
>>> > 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:
>>> 
>>> :0: warning: 'touchIDLockout' was deprecated in iOS 11.0: use 
>>> LAErrorBiometryLockout
>>> :0: warning: 'touchIDNotEnrolled' was deprecated in iOS 11.0: use 
>>> LAErrorBiometryNotEnrolled
>>> :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@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
>> 
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

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

[Dennis Weissmann via swift-users]

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  wrote:
>> 
>> On Nov 4, 2017, at 9:38 AM, Dennis Weissmann via swift-users 
>>  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:
>> 
>> :0: warning: 'touchIDLockout' was deprecated in iOS 11.0: use 
>> LAErrorBiometryLockout
>> :0: warning: 'touchIDNotEnrolled' was deprecated in iOS 11.0: use 
>> LAErrorBiometryNotEnrolled
>> :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@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
> 
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

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

[Charles Srstka via swift-users]

> On Nov 4, 2017, at 9:38 AM, Dennis Weissmann via swift-users 
>  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:
> 
> :0: warning: 'touchIDLockout' was deprecated in iOS 11.0: use 
> LAErrorBiometryLockout
> :0: warning: 'touchIDNotEnrolled' was deprecated in iOS 11.0: use 
> LAErrorBiometryNotEnrolled
> :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@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

___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

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

[Dennis Weissmann via swift-users]

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:

:0: warning: 'touchIDLockout' was deprecated in iOS 11.0: use 
LAErrorBiometryLockout
:0: warning: 'touchIDNotEnrolled' was deprecated in iOS 11.0: use 
LAErrorBiometryNotEnrolled
: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@swift.org
https://lists.swift.org/mailman/listinfo/swift-users