Skip to content

Conversation

@rjmccall
Copy link
Contributor

@rjmccall rjmccall commented Nov 28, 2018

Summary of the changes:

  • Error type parameter must now conform to Swift.Error
  • Making Swift.Error conform to itself (allowing Swift.Error to be the second argument) is now part of this review
  • case success has been renamed to value
  • case failure has been renamed to error
  • value(), error(), and isSuccess accessors have been removed
  • fold has been removed
  • unwrapped is no longer in a conditional extension
  • flatMap overload that took a throwing closure has been removed
  • init that catches the result of a throwing closure has gained a parameter label

@rjmccall
Copy link
Contributor Author

@jshier Jon, we've written up some revisions to the proposal; please look them over and let us know what you think. We'd like to put this back up for review.

@jshier
Copy link
Contributor

jshier commented Nov 28, 2018

What limitations will be lifted to enable the use of Result<Value, Error: Swift.Error> ergonomically? Presumably something that would enable typealias ErrorResult<Value> = Result<Value, Swift.Error>? It would probably be good to outline that.

Otherwise, while the loss of functionality is unfortunate (especially the properties and unwrapped()), I think it looks okay. I guess I'll have to put my effort behind those enum enhancements now. 😄

@rjmccall
Copy link
Contributor Author

unwrapped() is still there, it just doesn't need to be in a conditional extension anymore.

I've clarified what's going on with Swift.Error and its self-conformance. Does that look better?

@jshier
Copy link
Contributor

jshier commented Nov 28, 2018

That looks good. It's hard to evaluate the ergonomics of the type without actually being able to use it. While it wouldn't be in Swift 5, is it expected to be in master anytime soon? It doesn't have to be in the proposal, but it would be good to know what the timeline would be here.

@rjmccall
Copy link
Contributor Author

You mean the self-conformance change? You need to build a compiler with swiftlang/swift#20629.

@rjmccall rjmccall merged commit db086de into swiftlang:master Nov 28, 2018
@rjmccall rjmccall deleted the result-revisions branch November 28, 2018 22:30
@jshier
Copy link
Contributor

jshier commented Nov 28, 2018

Ah, great! What should I do about the implementation PR?

@rjmccall
Copy link
Contributor Author

If you'd like to rebase it on top of that PR and make the proposed modifications, that would probably be best.

@jshier
Copy link
Contributor

jshier commented Nov 29, 2018

Great! I should get to that in the next couple of days, this weekend at the latest.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants