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 <felix...@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@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@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
