<div dir="ltr">On Sun, Apr 30, 2017 at 5:05 PM, Gor Gyolchanyan <span dir="ltr"><<a href="mailto:gor@gyolchanyan.com" target="_blank">gor@gyolchanyan.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div><span class="gmail-"><blockquote type="cite"><div>On May 1, 2017, at 12:10 AM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>> wrote:</div><br class="gmail-m_5116877186566974179Apple-interchange-newline"><div>You may wish to read the rationale behind the current error handling design:<br><br><a href="https://github.com/apple/swift/blob/master/docs/ErrorHandlingRationale.rst" target="_blank">https://github.com/apple/<wbr>swift/blob/master/docs/<wbr>ErrorHandlingRationale.rst</a><br><br>A Result type like you suggest has been considered and rejected in favor of the current design. Briefly, optionals and throwing errors are distinct because they are considered superior ways for handling distinct types of error.<br><br>In the case of a simple domain error, there is only one way to fail; therefore, optional return values are considered the best way to model that error.<br><br>In the case of a recoverable error, the document above describes why marked propagation (the current implementation in Swift) is considered superior to typed propagation (your suggestion).<br></div></blockquote></span><div><div><br></div><div>My proposal is not about replacing Optionals and throwing functions with a Result type, it’s about separating the representation of an error from its propagation.</div><div>Optionals and throwing functions solve two different problems, but they are not dealing with two different types of error.</div></div></div></div></blockquote><div><br></div><div>The basic premise of Swift error handling design is that there exist different types of error. From the document:</div><div><br></div><div>> What is an error? There may be many different possible error conditions in a program, but they can be categorized into several kinds based on how programmers should be expected to react to them. Since the programmer is expected to react differently, and since the language is the tool of the programmer's reaction, it makes sense for each group to be treated differently in the language.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div><div>Optionals are for storing and representing a value that might not exist (most commonly due to an unambiguous error).</div><div>Error handling is for propagating an error.</div><div>Returning an optional is essentially the same as returning a non-optional and throwing a dedicated “something went wrong” error, because due to the optional unwrapping mechanic, you cannot avoid dealing with the fact that there might have been an error. Optionals only allow you to delay the inevitable error handling, not avoid it. The use cases where the exact reason for an error is no important have nothing to do with whether or not that error should be available. The optional chaining, if-let statements and all other ways one might try to handle an optional value do not fundamentally require lack of error information.</div><div>The error handling mechanism, on the other hand, does not concern itself with representing the error, but only propagating it. Even an optional value with a general-purpose .none case has different levels of importance in different cases. More often than not, when propagating an optional value to a non-optional target, you’ll be stuck with dealing with the error immediately, which is exactly what throwing functions force you to do.</div><div>I suggest we enhance the current error representation and propagation mechanisms to be able to seamlessly handle cases where an erroneous value need to be stored as-is (along with its error) or unpacked and propagated (by throwing the error), not just representing a general “error”.</div><div>The general use case is to be able to catch a throwing call into an enum that stores the value or the error and then being able to unpack it in a throwing context (unpack it or throw the error).</div><div>This use case is a strict superset of the current Optional mechanic (catching a potentially missing value) and error handling (always manually throwing an error after manual checks).</div><div>The aforementioned suggestion about how to do that is indeed faulty, as pointed out by Robert Widmann, but the problem is still valid, in my opinion.</div></div></div></div></blockquote><div><br></div><div>I'd highly recommend taking some time to digest the existing rationale. You're basing your argument on contradicting the fundamental premise of the existing design, which begins with this: (a) there are different types of error; (b) the programmer is expected to react differently to different types of error; (c) the language is a tool to help the programmer react; (d) optionals and errors are not unified, and unification is a non-goal, because they are designed to help the programmer react differently to different types of error.</div><div><br></div><div>Do you have a specific use case in mind that is not well accommodated by optionals or by throwing functions? What is it? Into what category does that use case fall, in terms of the types of error enumerated in the error handling rationale document?</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div class="gmail-h5"><div><blockquote type="cite"><div><div class="gmail_quote"><div dir="ltr">On Sun, Apr 30, 2017 at 13:51 Gor Gyolchanyan via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><br>
> On Apr 30, 2017, at 9:29 PM, Robert Widmann <<a href="mailto:devteam.codafi@gmail.com" target="_blank">devteam.codafi@gmail.com</a>> wrote:<br>
><br>
><br>
>> On Apr 30, 2017, at 1:43 PM, Gor Gyolchanyan <<a href="mailto:gor@gyolchanyan.com" target="_blank">gor@gyolchanyan.com</a>> wrote:<br>
>><br>
>> It doesn’t have to be a massive source-break, since this pitch is supposed to be a strict superset of what Optional and throwing is currently.<br>
>> The only thing that I can think of at this moment that would break is this syntax:<br>
>><br>
>> let foo: Int? = .none // Error: Can’t convert (Error) -> Int? to Int?<br>
>><br>
><br>
> Except it’s not a strict superset if you break every use of this case as an RValue. Especially when so much of Swift’s syntax and major patterns revolve around the manipulation of optionals.<br>
><br>
>> The ExpressibleByNilLiteral, the try/throw syntax, all of those things would work as they are right now.<br>
>> Error handling as it is currently, is essentially a hidden `error` out parameter and a whole bunch of codegen.<br>
>> Even the semantical changes described earlier would be purely additive.<br>
><br>
> Don’t get me wrong, I think you’ve identified the problem space well, I just disagree with the solution.<br>
<br>
Yeah, you’re right. It would take some next-level fixits to deal with the consequences of changing the most fundamental data type of Swift I can think of.<br>
I’d really appreciate it if you’d offer an alternative solution to this problem.<br>
The problem, as I understand it, is as follows:<br>
<br>
A lot of Swift’s logic revolves around the notion that some values might be missing for whatever reason and some functions might fail for whatever reason.<br>
Any function’s effect can be summed up as the union of its return value and the global state that it changes (that includes captured closure scopes).<br>
This could be boiled down to the statement that “Values that a function sets and returns completely express the purpose of the function”.<br>
The optional gives an extremely convenient way of representing values that might not exist (which, when returned from a function often means “failed for an unknown reason”).<br>
The fact that Optional is a type, rather then a function attribute allows us to store and imperatively manipulate the outcome of logically failable functions, but unfortunately, it doesn’t allow us to reason about the cause of the failure.<br>
On the other hand, throwing functions captures the logic of dealing with specific failures very well, but does not allow us to store and manipulate them easily, leaving us with workarounds like wrapping errors in enums with values and re-throwing the errors on their way out of the generic pipeline.<br>
I’d like to come up with a solution that would unify the optionals and the throwing functions into a single mechanism for dealing with the concept of failure, taking the best of both worlds and getting the benefits of the new synergies.<br>
This pitch was a first rough idea about the direction in which we could go in trying to find a solution.<br>
I chose to enhance Optional instead of introducing a new type like Failable, so that we could make do with minimal language changes and migration procedures.<br>
<br>
This problem is kinda similar to the variadic parameter problem, which makes it impossible to forward calls to variadic functions simply because that feature is too magical and does not provide a way to store and propagate its logic.<br>
<br>
Another way I could think of solving it would be to allow overloading the postfix `!` and `?` operators (which would currently only be defined for Optionals), which would allow us to define the Failable enum type with some error handling syntax integration and make it feel more at home in the midst of Optionals.<br>
<br>
Or better yet, make an OptionalProtocol and move the current magical logic to it, leaving the existing Optional perfectly intact and allowing userspace implementations.<br>
This would also greatly benefit numerous use cases of “invalidatable” types (like file handlers that can be closed) that would no longer have to either fatalError or use unwieldy wrappers that operate on Optionals.<br>
<br>
> ~Robert Widmann<br>
><br>
>><br>
>>> On Apr 30, 2017, at 8:35 PM, Robert Widmann <<a href="mailto:devteam.codafi@gmail.com" target="_blank">devteam.codafi@gmail.com</a>> wrote:<br>
>>><br>
>>> This "revamp" is isomorphic to adding a Sum type to stdlib and plumbing error handling syntax through. I'd much rather see that than the massive source-break this would entail.<br>
>>><br>
>>> ~Robert Widmann<br>
>>><br>
>>> 2017/04/30 13:11、Gor Gyolchanyan via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> のメッセージ:<br>
>>><br>
>>>> I’d like to suggest a bit of redesigning the Optional type and throwing functions to provide a single powerful and flexible mechanism for dealing with unexpected situations.<br>
>>>><br>
>>>> In short, The Optional would have an associated value of type Error added to its `none` case, which would describe the reason why the wrapped value is missing.<br>
>>>><br>
>>>> public enum Optional<Wrapped> {<br>
>>>><br>
>>>> case .some(Wrapped)<br>
>>>><br>
>>>> case .none(Error)<br>
>>>><br>
>>>> }<br>
>>>><br>
>>>> The Optional's ExpressibleByNilLiteral would initialize it with an error that corresponds to what is currently fatalError-ed as "unexpectedly found nil while unwrapping an Optional value".<br>
>>>><br>
>>>> The forced unwrapping operator (postfix `!`) would behave the same way as it does now, except in case of a fatal error it would print out the underlying error, instead of the aforementioned hard-coded string.<br>
>>>><br>
>>>> The optional chaining operator (postfix `?`) would behave the same way as it does now, except when it stops evaluating and returns the Optional, it would contain the error, returned by the sub-expression that failed to evaluate.<br>
>>>><br>
>>>> Any throwing function would be equivalent to a function that returns an Optional. If the function is declared as throwing and returning an Optional at the same time, it would be equivalent to a function returning an Optional Optional.<br>
>>>><br>
>>>> The if-let statement would bind the `let` variable to the wrapped value inside the "then" block and would bind it to the error in the "else" block. Chained else-if blocks would all be considered part of the overarching "else" block, so all of them would be able to access the error bound to the if-let name.<br>
>>>><br>
>>>> The guard-let and case-let statements are essentially just rewrites of if-let with some added logic.<br>
>>>><br>
>>>> The `try` keyword, applied to an optional would behave like this:<br>
>>>><br>
>>>> public func try<T>(_ optional: T?) throws -> T {<br>
>>>> guard let wrapped = optional else {<br>
>>>> throw wrapped // Remember, if-let, guard-let and case-let statements bind the let name to the error in case of a failure.<br>
>>>> }<br>
>>>> return wrapped<br>
>>>> }<br>
>>>><br>
>>>> Multiple let bindings in a single if-let statement are essentially rewrites of a nested chain of if-let statements.<br>
>>>><br>
>>>> The `try` keyword applied to an optional would unwrap the value or throw the error.<br>
>>>> The `try?` keyword applied to a throwing function call would cause any thrown errors to be caught and put into the returned Optional, instead of simply ignored.<br>
>>>> The `try!` keyword applied to a throwing function call would behave as you'd expect: just like `try?` except immediately force-unwrapped.<br>
>>>><br>
>>>> A throwing function would be convertible to a non-throwing optional-returning function and vice versa.<br>
>>>> This would allow making use of throwing functions when dealing with generics or protocols that allow arbitrary return types, without having to sacrifice the convenience of error-handling logic. Conversely, it would allow to write generic code that deals with any type of function without having to implement special cases for throwing functions. This means that the two function types would be interchangeable and one would be able to satisfy protocol requirements of the other. The `rethrows` idiom would then become a natural consequence of writing generic functions that may return optional and non-optional results just as well.<br>
>>>><br>
>>>> ______________________________<wbr>_________________<br>
>>>> swift-evolution mailing list<br>
>>>> <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
>>>> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
>><br>
><br>
<br>
______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
</blockquote></div>
</div></blockquote></div><br></div></div></div></blockquote></div><br></div></div>