Adding Result II: Unconstrained Boogaloo

Evolution Pitches
5

I have also been thinking about Result, and my primary belief is that Result should both be as similar to Optional and extend as much of Optional's sugar as is reasonably unambiguous, as well as having much 'swift-error-model' specific sugar as possible.

In particular, I think the preferred way to make a Result should be by replacing the try in a throwing expression with "catch":

func throwing() throws -> T { /*...*/ }
let result: Result<T, Swift.Error> = catch throwing()

Also, I think that by symmetry with Optional.some the value case should also be called some, and its type should be called Wrapped.

enum Result<Wrapped, Failure> {
  case some(Wrapped)
  case error(Failure)
}

Finally, some sugar currently on Optional I think should certainly be extended to Result:

  • Any value of type T should be implicitly convertible to the .some(T) case of the Result type, as with T?.
  • The value? binding pattern (e.g. here) should also match the .some(T) case of the Result type, in addition to that of T?.
  • The postfix ! reserved operator should also be useable on a Result value, to assert it is in the .some case, and unwrap it if so.
3 Likes