What do you think of

guard let r = returnsResult(), case let .Succeed(m) = r else {
        return r 
}

Which binds r only within the scope of the guard as desired.

Written in multiple lines

guard 
        let r = returnsResult(), 
        case let .Succeed(m) = r 
else {
        return r 
}

-Thorsten 

> Am 24.12.2015 um 01:02 schrieb Andrew Duncan via swift-evolution 
> <[email protected]>:
> 
> Yes, which would revert to Brent’s suggestion. But you have generalized it in 
> a very compatible way.
> 
> As I read somewhere, improving programming languages comes from removing 
> limitations rather than adding features. I intend for this Pitch to be the 
> former, although it does kind of look like the latter.
> 
>> On 23 Dec, 2015, at 15:58, Joe Groff <[email protected]> wrote:
>> 
>> 
>>> On Dec 23, 2015, at 3:56 PM, Andrew Duncan <[email protected]> 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 <[email protected]> wrote:
>>>> 
>>>> 
>>>>> On Dec 23, 2015, at 10:16 AM, Andrew Duncan via swift-evolution 
>>>>> <[email protected]> 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
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to