SE-0235 - Add Result to the Standard Library

Evolution Proposal Reviews
88
  • What is your evaluation of the proposal?

+1 and long overdue! I've used Result and/or Either in every substantial code base I've worked in.

A few thoughts:

  1. I think map/mapError/flatMap/flatMapError are indispensable and nicely mirror the existing map/flatMap APIs on arrays and optionals.

  2. I think case success/var isSuccess/var value lack naming uniformity/cohesion. (Same with case failure/var isFailure/var error.) Why not name the properties after the case names?

  3. I think the isSuccess/value/isFailure/error properties are all band-aids around the fact that enums aren't as ergonomic as they should be. I pitched a more general solution for this awhile back: Automatically derive properties for enum cases

  4. I find fold extremely useful though I see it mostly as a band-aid around the fact that Swift doesn't have a lightweight expression-based switch statement. I'd probably still define a fold function, though, since it's handy for chaining and passing in functions as arguments, just like forEach.

  • Is the problem being addressed significant enough to warrant a change to Swift?

Yes.

  • Does this proposal fit well with the feel and direction of Swift?

Yes (other than some of my comments earlier about naming and presence of fields like isSuccess and value).

  • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

Yes and this proposal compares nicely.

  • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

In-depth study and experience.

4 Likes