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

Reply via email to