Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Swift 5.0 and Result in Standard Library #696

Closed
larryonoff opened this issue Dec 15, 2018 · 13 comments
Closed

Swift 5.0 and Result in Standard Library #696

larryonoff opened this issue Dec 15, 2018 · 13 comments

Comments

@larryonoff
Copy link

I think it's time to start preparation for the new features of Swift 5.0, i.e. Result that has been recently accepted to the standard library, see
https://github.com/apple/swift-evolution/blob/master/proposals/0235-add-result.md.

The issue that I see that migration to the Swift.Result is a breaking change since different signatures.

https://github.com/apple/swift-evolution/blob/master/proposals/0235-add-result.md

public enum Result<Value, Error: Swift.Error> {
    case value(Value), error(Error)
}

when https://github.com/antitypical/Result

public enum Result<Value, Error: Swift.Error> {
	case success(Value)
	case failure(Error)
}

I totally respect to https://github.com/antitypical/Result, but I think that it's better using Standard Library.

Any community thought about?

@mdiep
Copy link
Contributor

mdiep commented Dec 16, 2018

The accepted proposal is:

public enum Result<Success, Failure: Error> {
  case success(Success)
  case failure(Failure)
}

💯 we should use this.

antitypical/Result should also update to be a set of additions to the stdlib Result.

@larryonoff
Copy link
Author

@mdiep the accepted signature 1-by-1 to antitypical/Result. This's really great

@andersio
Copy link
Member

The tricky bit is NoError which could have been a typealias to Never, had it been conformed to Error in stdlib.

@mdiep
Copy link
Contributor

mdiep commented Dec 16, 2018

The tricky bit is NoError which could have been a typealias to Never, had it been conformed to Error in stdlib.

Never is conformed to Error now.
swiftlang/swift#16857

@andersio
Copy link
Member

Argh! That’s brilliant. Missed that part from the SE proposal.

@larryonoff
Copy link
Author

Result already updated for Swift 5.0, see antitypical/Result#278

@andersio
Copy link
Member

andersio commented Jan 1, 2019

Assuming antitypical/Result would just be augmenting the stdlib Result since Swift 5, should we consider dropping antitypical/Result as a dependency?

RAS depends on NoError, the structural definition of Result and ResultProtocol. The former two can be sourced from the stdlib since Swift 5. The last one is used only for extension constraint for dematerialize(), which can be re-declared in RAS, and later replaced by parameterised extension when it lands.

@larryonoff
Copy link
Author

I think it can just be extensions in ReactiveSwift without Result dependency.

@mdiep
Copy link
Contributor

mdiep commented Jan 2, 2019

Assuming antitypical/Result would just be augmenting the stdlib Result since Swift 5, should we consider dropping antitypical/Result as a dependency?

Yes, I think so. 👍

@NachoSoto
Copy link
Member

Oh I missed this. I started the process: #702. I'm excited to make ReactiveSwift dependency-free :)

@larryonoff
Copy link
Author

@NachoSoto great to see pilots here :)

@Kalvin126
Copy link

@larryonoff I think we could close this issue now that #702 Swift.Result migration is merged?

@NachoSoto
Copy link
Member

👍🏻

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

No branches or pull requests

5 participants