Add an `always` method on EventLoopFuture #981

Palleas · 2019-04-27T05:20:15Z

Motivation:

#665

Modifications:

Add always in EventLoopFuture.swift
Add tests

Result:

NIO Users will be able to use .always to, well, always run an action
whether the future succeed or not.

swift-nio-bot · 2019-04-27T05:20:17Z

Can one of the admins verify this patch?

swift-nio-bot · 2019-04-27T05:20:17Z

Can one of the admins verify this patch?

swift-nio-bot · 2019-04-27T05:20:17Z

Can one of the admins verify this patch?

swift-nio-bot · 2019-04-27T05:20:17Z

Can one of the admins verify this patch?

swift-nio-bot · 2019-04-27T05:20:17Z

Can one of the admins verify this patch?

Lukasa

One minor nit, otherwise looks great.

Lukasa · 2019-04-29T10:20:45Z

Sources/NIO/EventLoopFuture.swift

+
+
+extension EventLoopFuture {
+


Minor nit: can we remove this whitespace?

@Lukasa Done!

Lukasa

Looks good to me, I'll get @weissi to review as well.

weissi · 2019-04-30T11:07:58Z

Sources/NIO/EventLoopFuture.swift

+    /// - parameters:
+    ///     - callback: the callback that is called when the `EventLoopFuture` is fulfilled.   
+    /// - returns: the current `EventLoopFuture`
+    public func always(_ callback: @escaping () -> Void) -> EventLoopFuture<Value> {


@Lukasa do you think we should give users the result here? For whenComplete we hand them the result so why not here?

FWIW I just came across a case where having the above with the result (or alwaysSuccess/alwaysError) would have been helpful.

I don't think I mind particularly. Arguably there are a family of functions here (giving them the name always for now though the compiler wouldn't like it much) created by twiddling both the return value of the function and the return value of the closure it accepts:

Future<T>.always(_: () -> Void) -> Future<T>

Future<T>.always(_: () -> Void) -> Void

Future<T>.always(_: (Result<T, Error>) -> Void) -> Future<T>

Future<T>.always(_: (Result<T, Error>) -> Void) -> Void

Future<T>.always(_: (Result<T, Error>) -> U) -> Future

Future<T>.always(_: (Result<T, Error>) -> Future) -> Future

Future<T>.always(_: (Result<T, Error>) -> Future<Void>) -> Future<T>

This proposal covers (1). (4) is currently spelled whenComplete. (3) is what you're proposing instead, and can do everything (1) can do at the cost of being a bit noisier in the code when you want (1). (2) is what whenComplete used to be in NIO 1, before we had a Result type to use.

(5) is arguably a function that would be called mapBoth, and (6) would be flatMapBoth by analogy. (7) is akin to (4) but allows returning a Future while persisting the result of the computation.

I think there could be a case made for providing all of these functions: the biggest challenge would be providing descriptive names, as we cannot rely on the compiler to provide overload resolution. (7) is the least obviously useful.

I think we should stick with always being the name for this function. We should also provide (3) and call it something like alwaysWithResult. Otherwise we'll force a lot of people to write always { _ in } and that kinda sucks.

@Lukasa Mostly agree, just that for whenComplete we decided to only offer the 'with result' case (but we didn't name it whenCompleteWithResult). Therefore, I'm not sure if for always we should do always and alwaysWithResult... But I agree that the _ in kinda sucks and obviously that the compiler won't like overloading at all. I'd probably still go for consistency with whenComplete.

No strong opinion here, I'm happy to follow your preference.

@weissi @Lukasa If there's a version providing the result then I'd think alwaysWithSuccess and alwaysWithError would probably be requested too? Providing a value like this is pretty close to Java's peek.

If that's the case then maybe these are distinct from the always as it stands at the moment?

Future<T>.always(_: () -> Void) -> Future<T> Future<T>.peek(_: (T) -> Void) -> Future<T> Future<T>.peekError(_: (Error) -> Void) -> Future<T> Future<T>.peekResult(_: (Result<T, Error>) -> Void) -> Future<T>

Heh, I kind of like the peeks. My only concern with leaving always as is would be always not giving you a value but whenComplete giving you the result. Just looks a bit inconsistent, that's all :). Especially that in NIO 1 we had whenComplete giving you nothing and we switched to whenComplete giving you the result for NIO2 :).

True, it's probably best to be consistent with whenComplete even though I prefer the NIO 1 version of it! I think I ignore the result more often than not...

I would vote to change it back in some future version of NIO and introduce whenResult to be closer in name to the other methods which provide a Result to the callback. The above would then be analogues of the when{Complete,Success,Failure,Result} which return the future.

Sounds good. when{Complete,Success,Failure,Result} make sense to me. Filed #986

@Palleas just talked to @Lukasa about this. Let's add the Result<...> to the closure for always for consistency with whenComplete. The cleanup and providing the other missing methods can be done as #986 .

Palleas · 2019-04-30T15:25:08Z

@Lukasa fixed the failing build, sorry about that. I'm slowly engraving in my brain the reflex of running the sanity check locally.

Motivation: apple#665 Modifications: * Add `always` in EventLoopFuture.swift * Add tests Result: NIO Users will be able to use `.always` to, well, always run an action wether the future succeed or not.

weissi

Thank you! This looks mostly good but we should add the Result for consistency

Motivation: Can be useful to developers and is consistent with the rest of the codebase Modifications: Add `Result<Value, Error>` to the callback Result: Result is available

Palleas · 2019-05-09T02:54:04Z

@weissi your wish is my command 🙇

weissi

Thank you! Looks good to me.

Lukasa requested changes Apr 29, 2019

View reviewed changes

Lukasa added the 🆕 semver/minor Adds new public API. label Apr 29, 2019

Lukasa added this to the 2.1.0 milestone Apr 29, 2019

Palleas force-pushed the romain/add-always branch 2 times, most recently from 7778e37 to 0195ebc Compare April 29, 2019 15:42

Lukasa approved these changes Apr 29, 2019

View reviewed changes

Lukasa requested a review from weissi April 29, 2019 16:48

weissi reviewed Apr 30, 2019

View reviewed changes

Palleas force-pushed the romain/add-always branch 2 times, most recently from a87379a to aaadfba Compare April 30, 2019 15:24

Add an always method on EventLoopFuture

4d9771a

Motivation: apple#665 Modifications: * Add `always` in EventLoopFuture.swift * Add tests Result: NIO Users will be able to use `.always` to, well, always run an action wether the future succeed or not.

Palleas force-pushed the romain/add-always branch from aaadfba to 4d9771a Compare April 30, 2019 15:25

Romain Pouclet and others added 2 commits May 1, 2019 17:24

Merge branch 'master' into romain/add-always

c09cb6b

Merge branch 'master' into romain/add-always

55c8758

weissi requested changes May 8, 2019

View reviewed changes

Pass the result as argument of the always closure

839fe11

Motivation: Can be useful to developers and is consistent with the rest of the codebase Modifications: Add `Result<Value, Error>` to the callback Result: Result is available

Merge branch 'master' into romain/add-always

f122567

weissi approved these changes May 9, 2019

View reviewed changes

Update EventLoopFuture.swift

f22c1cb

Lukasa modified the milestones: 2.1.0, 2.2.0 May 9, 2019

Palleas and others added 2 commits May 9, 2019 11:20

Merge branch 'master' into romain/add-always

f1499a1

Merge branch 'master' into romain/add-always

abcfa3c

Merge branch 'master' into romain/add-always

8823fc4

weissi merged commit c59c193 into apple:master May 15, 2019

Palleas deleted the romain/add-always branch May 15, 2019 18:02

weissi mentioned this pull request May 20, 2019

futures should have an always or something #665

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add an `always` method on EventLoopFuture #981

Add an `always` method on EventLoopFuture #981

Palleas commented Apr 27, 2019

swift-nio-bot commented Apr 27, 2019

swift-nio-bot commented Apr 27, 2019

swift-nio-bot commented Apr 27, 2019

swift-nio-bot commented Apr 27, 2019

swift-nio-bot commented Apr 27, 2019

Lukasa left a comment

Lukasa Apr 29, 2019

Palleas Apr 29, 2019

Lukasa left a comment

weissi Apr 30, 2019

glbrntt Apr 30, 2019

Lukasa Apr 30, 2019

weissi Apr 30, 2019

Lukasa Apr 30, 2019

glbrntt Apr 30, 2019

weissi Apr 30, 2019

glbrntt Apr 30, 2019

weissi Apr 30, 2019 •

edited

Loading

weissi May 8, 2019

Palleas commented Apr 30, 2019

weissi left a comment

Palleas commented May 9, 2019

weissi left a comment



		extension EventLoopFuture {

Add an always method on EventLoopFuture #981

Add an always method on EventLoopFuture #981

Conversation

Palleas commented Apr 27, 2019

swift-nio-bot commented Apr 27, 2019

swift-nio-bot commented Apr 27, 2019

swift-nio-bot commented Apr 27, 2019

swift-nio-bot commented Apr 27, 2019

swift-nio-bot commented Apr 27, 2019

Lukasa left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Lukasa left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

weissi Apr 30, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Palleas commented Apr 30, 2019

weissi left a comment

Choose a reason for hiding this comment

Palleas commented May 9, 2019

weissi left a comment

Choose a reason for hiding this comment

Add an `always` method on EventLoopFuture #981

Add an `always` method on EventLoopFuture #981

weissi Apr 30, 2019 •

edited

Loading