Pitch: `guard try` — error-aware early exit

[aucl (Clemens)]

@pyrtsa

Otherwise (if -> Void), one would need to write it as:

guard case () = try validate(something) catch { ... }

interestingly this even works, only the guard is not aware of the throwing.

do {
    guard case () = try foo() else {
        // 'guard' condition is always true, body is unreachable
    }
} catch { }

[tera]

@aucl

do { guard try foo() else { // Cannot convert value of type '()' to expected condition type 'Bool'

I meant func foo() throws -> Bool there.

[michelf (Michel Fortin)]

@aucl

guard let  ... = try <expression>
else { throw ElseError }
catch { } // Catches ElseError

Is there any use case for that though? To me it sounds like a trap people would fall into if allowed, and it’s on the error path which tend to be less well tested.

But lets say we allow it, can we interleave both?

guard let  ... = try <expression>
catch { } // Catches only from <expression>
else { throw ElseError }
catch { } // Catches ElseError

[CrystDragon (Lincoln Wu)]

How about a new guard do syntax:

guard do {
  try anything()
} catch {
  // must stop executing the enclosing scope, eg.
  return xxx // OK
  throw error // OK
}

This syntax will be more composable in my opinion.

[mirza-garibovic (Mirza)]

I wonder if we can avoid introducing new special case syntax by making do…catch an expression? Then you could combine it with guard like any other expression. It would look like this:

guard let x = (do { try f() } catch { log(error); nil }) else { return }

[xwu (Xiaodi Wu)]

You'll be glad to know that there are 949 posts (now 950) on that exact topic!

[Pitch] Last expression as return value

I still believe this is a great feature provided it is disabled for discardable results: func cook(vegetable: Vegetable) -> Vegetable { print("Bzzzz") vegetable.cook() // Error: discardableResult functions need explicit return! } func cook2(vegetable: Vegetable) -> Vegetable { print("Bzzzz") Vegetable() // fine } thus fixing the regression mentioned in the headline post and making it less non-obvious. This feature naturally promotes "single ex…

[MinerMinerMain]

@aucl

Some thought about the scope of catching. It could by the order of the else and catch blocks. Basically to catch everything between the try and the catch block.
If the else block is in the front, it is also caught, if it is in the end, would t

guard let  ... = try <expression>
else { throw ElseError }
catch { } // Catches ElseError

guard let  ... = try <expression>
catch { } // Catches only from <expression>
else { throw ElseError }

In case we would like the scopeless do <expression> catch {} it could also work if it became an expression as well (like if, and switch from 5.9).

Overall allowing for a block from a guard clause, besides the criterion, to potentially enter into a block with the same context would break the expectation that guard is meant to prevent invalid, irreconcilable or undesired execution states from reaching a potential downstream input into a fragile or critical execution path and safely departing with an appropriate context departure state or resulting in further execution being unable to occur via a Never function.

If a guard clause’s exit blocks ever returns to the context the guard clause originated from then something has gone drastically wrong during execution and compilation.

If you do want to catch errors from a guard clause’s blocks; my advice is to make a new context with do, or catch the errors within the block before it exits the context. Doing this is more semantically clear and communicates better the intent of the result needs to be caught instead of any positional requirements, if you are throwing errors to correct them in the same statement but a different block you should reconsider the structure of the throwing block to have the catch clause be contained in the throwing block rather than a different block.

Making it easy to juggle how blocks connect with language features, like guard having the capacity to catch from the blocks which are intended to be safe exit paths, would also go against the Idea that Swift should make it easier to write clear and correct code.

TLDR:
Catching from a guard clause’s blocks from within the same context is fully incongruent with the conceptual expectations of guard in Swift’s syntax regardless of if they are both contained in the same clause or statement.