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

Allow promises to be completed with a `Result<Value, Error>` #1124

Merged
merged 3 commits into from Sep 10, 2019

Conversation

@glbrntt
Copy link
Contributor

commented Aug 29, 2019

Motivation:

When dealing with Result types and promises it is inconvenient having to
switch over the result in order to succeed or fail a promise.

Modifications:

  • Allow promises to be completed with a Result<Value, Error> directly.
  • Added tests.

Result:

Promises are easier to fulfill with Result types.

Allow promises to be completed with a `Result<Value, Error>`
Motivation:

When dealing with `Result` types and promises it is inconvenient having to
switch over the result in order to succeed or fail a promise.

Modifications:

- Allow promises to be completed with a `Result<Value, Error>` directly.
- Added tests.

Result:

Promises are easier to fulfill with `Result` types.
/// - parameters:
/// - result: The result which will be used to succeed or fail this promise.
@inlinable
public func completeWith(_ result: Result<Value, Error>) {

This comment has been minimized.

Copy link
@glbrntt

glbrntt Aug 29, 2019

Author Contributor

Not super happy about the overloading of completeWith but didn't want to add an explicit result label.

This comment has been minimized.

Copy link
@weissi

weissi Aug 29, 2019

Member

let's CC @Lukasa & @normanmaurer for the naming. Could also always do public func fulfill(_ result: Result)?

This comment has been minimized.

Copy link
@ktoso

ktoso Aug 29, 2019

Member

So far I've not yet seen how such kind of overload could end up being problematic... as it reads quite well (and going for another name like fulfill or other, seems a bit ad hoc if only to avoid an overload) I'm not sure if avoiding the overload is worth it here... Any secret swift knowledge I'm missing about such specific overload is bad?

(more complex ones, esp. with differing return types I'd be on board with avoiding, here it seems to help more than hurt I thought)


Main point about not using a different name is consistency; why would I be able to bla: p.fulfull with a result, but not a future? I should be able to do the same style of completing with either, thus if we have one name we're stuck with; sticking with it is better than ad hoc making new names for semanticslly very "same"-ish operations.

This comment has been minimized.

Copy link
@glbrntt

glbrntt Aug 29, 2019

Author Contributor

I'm actually fine with completeWith(_ result: Result) but I know not everyone is a fan of overloads which is why I called it out.

I'm 👎 on fulfil for the consistency reason.

This comment has been minimized.

Copy link
@weissi

weissi Aug 29, 2019

Member

I don't like overloads but in this particular case I'm probably fine with it.

@weissi weissi added this to the 2.8.0 milestone Aug 29, 2019

@weissi weissi requested a review from Lukasa Aug 29, 2019

@weissi
weissi approved these changes Aug 29, 2019
Copy link
Member

left a comment

Thank you! lgtm but let's wait for @Lukasa or @normanmaurer.

@weissi

This comment has been minimized.

Copy link
Member

commented Sep 9, 2019

@swift-nio-bot test this please

@weissi

This comment has been minimized.

Copy link
Member

commented Sep 9, 2019

@Lukasa are you happy with this API?

@Lukasa
Lukasa approved these changes Sep 10, 2019
Copy link
Contributor

left a comment

Yup, fine with this.

@Lukasa Lukasa merged commit 9201908 into apple:master Sep 10, 2019

4 checks passed

pull request validation (5.0) Build finished.
Details
pull request validation (5.1) Build finished.
Details
pull request validation (api breakage) Build finished.
Details
pull request validation (sanity) Build finished.
Details

@glbrntt glbrntt deleted the glbrntt:gb-promise-result branch Sep 10, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.