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

[Andrew Duncan]

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?

> On 23 Dec, 2015, at 6:59, Félix Cloutier <felixcca at yahoo.ca> wrote:
> 
> I feel exactly like Brent.
> 
> Félix
> 
>> Le 23 déc. 2015 à 04:15:24, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org> a écrit :
>> 
>>>  guard case let .Succeed(m) = returnsResult() else {
>>>       return it
>>>  }
>>>  // Can safely use m, otherwise Result is passed back the call stack.
>> 
>> I didn't understand what you wanted to begin with, so to summarize: you want to be able to bind the return value of `returnsResult()` to a constant on the `else` branch if the pattern doesn't match.
>> 
>> I definitely see the use case here, but I can't say I like the implicit use of `it`. If we did something like this, I would prefer it be done by decorating the `else`:
>> 
>> 	guard case let .Succeed(m) = returnsResult() else let r {
>> 		return r
>> 	}
>> 
>> However, I'm honestly not sure that's much less burdensome than this:
>> 
>> 	let r = returnsResult()
>> 	guard case let .Succeed(m) = r else {
>> 		return r
>> 	}
>> 
>> It *is* a line less, and a constant less, but it also means adding a new and slightly funky syntax to the language. I'm just not sure it's worth it.
>> 
>> -- 
>> Brent Royal-Gordon
>> Architechies
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>