Wait, no, there's a problem with that. You can't use `r` in the guard scope
because `returnsResult()` might not have succeeded.
Félix
> Le 24 déc. 2015 à 09:37:36, Félix Cloutier via swift-evolution
> <swift-evolution@swift.org> a écrit :
>
> I like that it's consistent with the if syntax (even though I don't really
> like the if syntax) and that there's no dangling parts after the else.
>
> Félix
>
>> Le 24 déc. 2015 à 06:29:17, Thorsten Seitz via swift-evolution
>> <swift-evolution@swift.org> a écrit :
>>
>> 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
>>> <swift-evolution@swift.org>:
>>>
>>> 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 <jgr...@apple.com> wrote:
>>>>
>>>>
>>>>> On Dec 23, 2015, at 3:56 PM, Andrew Duncan <andrewzbo...@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 <jgr...@apple.com> wrote:
>>>>>>
>>>>>>
>>>>>>> On Dec 23, 2015, at 10:16 AM, Andrew Duncan via swift-evolution
>>>>>>> <swift-evolution@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
>>>
>>> _______________________________________________
>>> 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
>
> _______________________________________________
> 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
