[swift-evolution] [Pitch] Guarding on enum values

[Brent Royal-Gordon]

> On Dec 23, 2015, at 3:35 PM, Joe Groff via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> 
>> On Dec 23, 2015, at 10:16 AM, Andrew Duncan via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> In fact, I feel the same way too. I have definite views about indefinite pronouns. When I am teaching, I studiously avoid “it”, “this”, and “that”: at any given instant half the students have wandering minds, and if they miss the referent, they get lost. My old HyperTalk habits must be resurfacing with “it”. :)
>> 
>> I still think the use case is valuable as a (natural IMHO) generalization of guard, and feel the annoyance of having the bound variable show up three times and outlast the guard, when I don’t want to use or even see it. Brent’s suggestion removes the second objection and alleviates the first; I’ll see that, but ask if we can raise it. The pitch is:
>> 
>>   guard case let .Succeed(m) = returnsResult() else let r {
>>       return r
>>   }
>> 
>> Improvement! The question is: can we reduce this by one or two ‘r’s?
> 
> 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.

I thought a bit about that. Would it make sense to support multiple else blocks?

	guard case let .Succeed(m) = returnsResult()
	else if case .Failure("Temporary Failure") {
		return retry()
	}
	else case let .Failure(r) {
		return r
	}

-- 
Brent Royal-Gordon
Architechies