[swift-evolution] swift-evolution Digest, Vol 2, Issue 7

[Andrew Duncan]

>> 
>>  func recognizeHandler() throws {
>>    try {
>>        accept(.on)        // .on is an enum tag for the token for the ‘on’ keyword.
>>        recognizeName()
>>        recognizeFormalParamSeq()
>>        accept(.newline)
>>        recognizeCommandSeq()
>>        accept(.end)
>>        recognizeName()    // Later Visitor pass checks that names match. 
>>        accept(.newline)
>>    }
>>  }
> 
> 
> Indeed.  Also, FWIW, I’d argue that maybe the root problem here is that this code should not be using Swift’s error handling constructs in the first place.  An enum (or other approach) may be more appropriate.  Swift’s error handling design is intentionally driven by the idea that you shouldn’t use it if “everything throws” - in this situation, the sugar benefits of error handling are intentionally outweighed by the weight of the try keywords everywhere.  This is meant to force the balance over to using more manual techniques.
> 
> -Chris

Quite so. That is what prompted an earlier suggestion/request about guarding on Optionals:

  https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151221/004217.html

In fact, I did go with a construct like

    let r = returnsSucceedOrFailOptional()
    guard case let .Succeed(node) = r else { return r }  // Back down the call stack.
    // Safe to use node; r now irrelevant but in scope.

and put up with the fact that the unwanted r was still in scope. Alas, my LOC soared. More code, more bugs.

Apart from considerations of propriety, are there performance up/downsides to either approach?

- AMD