More progress! This sounds good, but it looks like what you intend is for r to
be the error message in the Result enum type.
enum Result {
case .Fail(String) // Error message
case .Succeed(MyType) // Something to work with
}
guard case let .Succeed(m) = returnsResult() else case let .Failure(r) {
return r // Looks like r is bound to the error String.
// But maybe you meant r = the entire returnsResult() result.
}
The sort of message-passing error-handling I have in mind is where each method
in the call chain returns a full Result enum and each stage checks it for
Succeed/Fail, and immediately bails on Fail, returning (propagating) the
Result. To be sure, this is sort of what exceptions do under the hood anyway.
My use-case is a recursive descent parser that I want to bail when a syntax
error is found. This could happen way deep in the stack of calls. If I
consistently return a .Fail(ErrorCode) or .Succeed(ASTNode) from each method, I
just pass on the Result in case of .Fail, or use it in case of .Succeed.
> On 23 Dec, 2015, at 15:35, Joe Groff <[email protected]> wrote:
>
>
>> On Dec 23, 2015, at 10:16 AM, Andrew Duncan via swift-evolution
>> <[email protected]> wrote:
>>
>
> A slight generalization would be to allow for an arbitrary pattern in the
> `else` clause:
>
> guard case let .Succeed(m) = returnsResult() else case let .Failure(r) {
> return r
> }
>
> with the requirement that the "guard" and "else" patterns form an exhaustive
> match when taken together. That feels nicer than special-case knowledge of
> two-case enums, though I admit it punishes what's likely to be a common case.
>
> -Joe
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
