futures should have an always or something

[weissi]

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?

[Lukasa]

Why does always return a T?

[weissi]

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

[normanmaurer]

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

[Lukasa]

@weissi Is this any different to:

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

Because we already have that.

[Lukasa]

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

[normanmaurer]

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]

@normanmaurer need both chaining and non-chaining variants

[normanmaurer]

@weissi why ?

[weissi]

@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]

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

[Lukasa]

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

[weissi]

@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]

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

[weissi]

@normanmaurer true

[Lukasa]

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

[normanmaurer]

@Lukasa but does it matter at all ?

[Lukasa]

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

[Palleas]

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

[weissi]

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.

[weissi]

Fixed by #981