> On Dec 23, 2015, at 3:56 PM, Andrew Duncan <andrewzbo...@gmail.com> wrote: > > 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. > }
I see. If it's an arbitrary pattern, you can match 'case let r' to bind the entire value instead of picking out the payload of the other case. That would still be exhaustive. -Joe > > 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 <jgr...@apple.com> wrote: >> >> >>> On Dec 23, 2015, at 10:16 AM, Andrew Duncan via swift-evolution >>> <swift-evolution@swift.org> 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 swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution