if let a = b, a.something() else - swift

Question

I have a code snippet here that works but am curious if there is a cleaner way to accomplish the same thing. I haven't seen anything exactly like this so far.
Logic I want to Achieve
The error is nil or is not a SpecialError
The error is non-nil BUT .foo() returns false
Code
enum SpecialError: Error {
func foo() -> Bool
}
let error: Error? // Some optional Error is passed in
if let myError = error as? SpecialError, myError.foo() {
// Don't care about this case
} else {
// This is the case I'm interested in
bar()
}
I'm curious if there is a better way to accomplish this if let else logic.

Answer 1

I may be misunderstanding, but it seems like nothing happens in the first branch of the if statement and you want to cut it down to just the second part? In that case, this should work for you:
if !((error as? SpecialError)?.foo() ?? false) {
bar()
}
This will execute bar() if:
1. error is nil
2. error is not a SpecialError
3. foo() returns false

Answer 2

The condition you want is for when the expression (error as? SpecialError)?.foo() evaluates to either:
nil, in which case error is not a SpecialError, or is nil.
false, in which case error is a SpecialError, but foo() returned false.
In your case, one way to express this is by taking advantage of the fact that the equality operators are overloaded for optionals, and saying:
if (error as? SpecialError)?.foo() != true {
bar()
}
As we're using the overload of != that compares optionals, true will be promoted to a Bool?, so we're checking that (error as? SpecialError)?.foo() is not a .some(true), which in this case is equivalent to checking if it is .some(false) or .none.

Answer 3

If I understand your question correctly, you're probably looking for something like this:
if !((error as? SpecialError)?.foo() ?? false) {

Answer 4

How about translating it exactly as you explained it:
if error == nil || !(error! is SpecialError) || !error!.foo() {
bar()
}
The short-circuiting of or will prevent the force unwraps of error from being a problem.

Answer 5

I think your code is hard to read, and John Montgomery's code is even harder to read and I predict it will be hard to maintain: imagine another developer looking at this code a year from now and asking you what it is doing, or even worse, that developer cannot ask you as you are no longer available. Imagine yourself looking at this code even even a couple months from now.
if let myError = error as? SpecialError, myError.foo() is convoluted, perhaps being a bit too clever. It contains too much logic to be long term readable by a team of developers.
Your first block could just check if myError is nil
Your second block could just check if is myError of type SpecialError
//you could use a guard statement here
if myError == nil {
return;
}
if let myError = error as? SpecialError {
//ok myError is type SpecialError it has a foo method I can call
if(myError.foo()) {
//do something
} else {
//do something else
}
} else { //myError not type SpecialError and is not nil
// This is the case I'm interested in
bar()
}

Answer 6

if let theFoo = (error as? SpecialError)?.foo(){
if theFoo != true{
bar()
} //in case you want to do handling if theFoo is true
} //in case you want to do handling if error is not SpecialError