Handle deprecated enum cases from a library

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

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

···

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

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) :thinking:

- Dennis

···

Sent from my iPhone

On 4. Nov 2017, at 10:42 PM, Charles Srstka <cocoadev@charlessoft.com> wrote:

On Nov 4, 2017, at 9:38 AM, Dennis Weissmann via swift-users <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
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

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

···

On Nov 5, 2017, at 3:14 AM, Dennis Weissmann <dennis@dennisweissmann.me> 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 :frowning:

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) :thinking:

- Dennis

Sent from my iPhone

Hi Charles,

I do believe you :slight_smile:

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 <cocoadev@charlessoft.com> wrote:

On Nov 5, 2017, at 3:14 AM, Dennis Weissmann <dennis@dennisweissmann.me> 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 :frowning:

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) :thinking:

- 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

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 :frowning:

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) :thinking:

- Dennis

Sent from my iPhone

On 4. Nov 2017, at 10:42 PM, Charles Srstka <cocoadev@charlessoft.com <mailto:cocoadev@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

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

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

···

On Nov 5, 2017, at 9:27 AM, Dennis Weissmann <dennis@dennisweissmann.me> wrote:

Hi Charles,

I do believe you :slight_smile:

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

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 <cocoadev@charlessoft.com> wrote:

On Nov 5, 2017, at 9:27 AM, Dennis Weissmann <dennis@dennisweissmann.me <mailto:dennis@dennisweissmann.me>> wrote:

Hi Charles,

I do believe you :slight_smile:

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

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 <http://bugs.swift.org/>?

Charles

···

On Nov 5, 2017, at 10:39 AM, Dennis Weissmann <dennis@dennisweissmann.me> 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

Hey Charles,

Thanks for going through this with me :slight_smile:

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 <cocoadev@charlessoft.com> wrote:

On Nov 5, 2017, at 10:39 AM, Dennis Weissmann <dennis@dennisweissmann.me <mailto:dennis@dennisweissmann.me>> 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 <http://bugs.swift.org/>?

Charles

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 <http://bugs.swift.org/> and hopefully it will get fixed.

Charles

···

On Nov 6, 2017, at 5:47 AM, Dennis Weissmann <dennis@dennisweissmann.me> wrote:

Hey Charles,

Thanks for going through this with me :slight_smile:

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

Hi! I'm wondering if anyone has reported this as a bug on bugs.swift.org yet? I would love to do something to help get this fixed, and I guess I could paste together something from this thread and this Stack Overflow answer, but if someone who actually understands the issue has already done it, that would of course be better. :)

1 Like

Please go ahead @skagedal, this somehow got lost and I forgot to report a bug.

  • Dennis
1 Like

Ah, there is a Swift bug from Ole Begemann. https://bugs.swift.org/browse/SR-6637 :+1:

1 Like

I'm not sure it's the exact same issue, but very similar to SR-8634, which was fixed.

@anthonylatsis That looks to me like a different thing? This is about warnings at the call site, or the not-even-call site – all that's needed to trigger the bug is to mention LAError. Like let foo: LAError? = nil.

Terms of Service

Privacy Policy

Cookie Policy