[swift-evolution] [Pitch] Guarding on enum values
Joe Groff
jgroff at apple.com
Wed Dec 23 17:58:57 CST 2015
> On Dec 23, 2015, at 3:56 PM, Andrew Duncan <andrewzboard at 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 <jgroff at apple.com> wrote:
>>
>>
>>> On Dec 23, 2015, at 10:16 AM, Andrew Duncan via swift-evolution <swift-evolution at 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
>
More information about the swift-evolution
mailing list