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

futures should have an `always` or something #665

Closed
weissi opened this issue Nov 27, 2018 · 20 comments

Comments

Projects
None yet
4 participants
@weissi
Copy link
Member

commented Nov 27, 2018

often you need to do some cleanup that needs to always happen, why not

extension EventLoopFuture {
    func always(_ body: () -> Void) -> EventLoopFuture<T>
}

that always runs?

@weissi weissi added the enhancement label Nov 27, 2018

@Lukasa

This comment has been minimized.

Copy link
Contributor

commented Nov 27, 2018

Why does always return a T?

@weissi

This comment has been minimized.

Copy link
Member Author

commented Nov 27, 2018

because it's too early in the morning 😂. fixing it :P

@normanmaurer

This comment has been minimized.

Copy link
Member

commented Nov 27, 2018

@weissi so this is something that will be executed no matter if the future is completed because of a failure or success ?

@Lukasa

This comment has been minimized.

Copy link
Contributor

commented Nov 27, 2018

@weissi Is this any different to:

public func whenComplete(_ callback: @escaping () -> Void)

Because we already have that.

@Lukasa

This comment has been minimized.

Copy link
Contributor

commented Nov 27, 2018

Oh, I see, it chains. Sure, why not.

@normanmaurer

This comment has been minimized.

Copy link
Member

commented Nov 27, 2018

If we do this then we should most likely just mark whenComplete as deprecated and introduce always but mark its return value as @discardableResult.

@weissi

This comment has been minimized.

Copy link
Member Author

commented Nov 27, 2018

@normanmaurer need both chaining and non-chaining variants

@normanmaurer

This comment has been minimized.

Copy link
Member

commented Nov 27, 2018

@weissi why ?

@weissi

This comment has been minimized.

Copy link
Member Author

commented Nov 27, 2018

@normanmaurer because otherwise you can't write this:

func runDatabaseQuery(_ query: String, database: DB) -> EventLoopFuture<[Row]> {
    return database.openConnetion { conn in
        conn.runQuery(query).always {
            conn.close()
        }
    }
}

You want to always close the DB connection. Currently you need to spell this

func runDatabaseQuery(_ query: String, database: DB) -> EventLoopFuture<[Row]> {
    return database.openConnetion { conn in
        let f = conn.runQuery(query)
        f.whenComplete {
            conn.close()
        }
        return f
    }
}

which is super ugly

@normanmaurer

This comment has been minimized.

Copy link
Member

commented Nov 27, 2018

@weissi I may need more coffee but I still dont get why we could not only have always at the end ?

@Lukasa

This comment has been minimized.

Copy link
Contributor

commented Nov 27, 2018

Yeah, I think @normanmaurer is right, we can just have always with a discardable result.

@weissi

This comment has been minimized.

Copy link
Member Author

commented Nov 27, 2018

@Lukasa we'll still allocate an extra, unnecessary future. We also have then & whenSuccess, thenIfError & whenFailure, but nothing & whenSuccess. I just want to fill the nothing-hole :)

@normanmaurer

This comment has been minimized.

Copy link
Member

commented Nov 27, 2018

@weissi why ? Couldn't it just return self in this case ?

@weissi

This comment has been minimized.

Copy link
Member Author

commented Nov 27, 2018

@Lukasa

This comment has been minimized.

Copy link
Contributor

commented Nov 27, 2018

Bear in mind that the semantics of that are slightly different than the semantics of returning a new future, though only slightly.

@normanmaurer

This comment has been minimized.

Copy link
Member

commented Nov 27, 2018

@Lukasa but does it matter at all ?

@Lukasa

This comment has been minimized.

Copy link
Contributor

commented Nov 27, 2018

Depends if you're trying to be really certain about future execution. Probably not though.

@Palleas

This comment has been minimized.

Copy link
Contributor

commented Apr 23, 2019

@normanmaurer @Lukasa @weissi Is that something we'd still want to add? 🤓

@weissi

This comment has been minimized.

Copy link
Member Author

commented Apr 23, 2019

I'm still very much in favour of having this, every time I use NIO as a user I want to have it :). Sure, it's pretty straightforward to work around but I often have something I need to close, a connection, a file, whatever and of course I want to do it always if there's an error or not.

Palleas added a commit to Palleas/swift-nio that referenced this issue Apr 27, 2019

Add an `always` method on EventLoopFuture
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 added a commit to Palleas/swift-nio that referenced this issue Apr 27, 2019

Add an `always` method on EventLoopFuture
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 added a commit to Palleas/swift-nio that referenced this issue Apr 29, 2019

Add an `always` method on EventLoopFuture
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 added a commit to Palleas/swift-nio that referenced this issue Apr 29, 2019

Add an `always` method on EventLoopFuture
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 added a commit to Palleas/swift-nio that referenced this issue Apr 30, 2019

Add an `always` method on EventLoopFuture
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 added a commit to Palleas/swift-nio that referenced this issue Apr 30, 2019

Add an `always` method on EventLoopFuture
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 added a commit to Palleas/swift-nio that referenced this issue Apr 30, 2019

Add an `always` method on EventLoopFuture
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 added a commit that referenced this issue May 15, 2019

Add an `always` method on EventLoopFuture (#981)
Add an `always` method on EventLoopFuture

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
wether the future succeed or not.
@weissi

This comment has been minimized.

Copy link
Member Author

commented May 20, 2019

Fixed by #981

@weissi weissi closed this May 20, 2019

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