[Revised] SE-0235: Add Result to the Standard Library

[koher (Yuta Koshizawa)]

I agree on the changes. In particular, it looks great to me that the Error type parameters is constrained to conform to Swift.Error, with self-conformance, and the Result type has minimum APIs.

@John_McCall

the core team agrees that this feature is worth adding to Swift

I want a guideline when to use the Result type. Opinions seems divided even in the Core Team as follows.

@Joe_Groff

Referring back to @John_McCall's original error handling rationale, I think throws and Result can be seen as addressing different corners of the design space. As the rationale describes, throws was designed for systemic errors, which tend to have a large distance between error source and error handler, so source and handler end up needing to be rather loosely coupled, which was a motivator for the exception-like propagation and lack of specific typing in the current throws feature. Result on the other hand is great for conditions that are intended to be immediately handled by the caller, for which being an regular return value with a more specific failure type is in fact the more convenient representation.

@John_McCall

I want to clarify that I favor adding Result only to address situations where manual propagation is necessary.

If I correctly understood, it seems like @Joe_Groff suggests that JSONDecoder.decode(_:from:) returns a Result and @John_McCall does not. I think errors from JSONDecoder.decode(_:from:) are something between simple domain errors and recoverable errors defined in "Error Handling Rationale and Proposal". Those errors are caused by some different conditions. nil is obviously insufficient to represent those errors. Also they don't require manual propagations. However they are not "systemic errors", and throws/try does not allow us to specify their error type (without typed throws). Should JSONDecoder.decode(_:from:) return a Result?