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 > <swift-users@swift.org> 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 <cocoa...@charlessoft.com > <mailto:cocoa...@charlessoft.com>> wrote: > >>> On Nov 4, 2017, at 9:38 AM, Dennis Weissmann via swift-users >>> <swift-users@swift.org <mailto:swift-users@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@swift.org <mailto:swift-users@swift.org> >>> https://lists.swift.org/mailman/listinfo/swift-users >>> <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
