Is there a use case where it would not be a good solution to simply have regular old guard give unwrapped variables inside the else clause if they just failed an "== nil" test?
guard error == nil else {
// use error here, as if already unwrapped
return
}
Syntactically, I sort of like @justrowingby's 'guard let...then' for indicating you want the inverted semantics, over the 'nguard', but I don't really like the idea of guard switching semantics at all.
(@tevamerlin's simple let inside the guard is a good solution as well.)
Of course it would be great if a bunch of these APIs would make use of Result now that have it.
The automatic unwrap I suggest wouldn't work if you had multiple nil comparisons:
guard thingOne == nil, thingTwo == nil else {
// no special behavior since we don't know which thing is not nil (or if both are)
return
}
guard thingOne == nil else {
// thingOne is unwrapped
return
}