RFC: function coroutine.finally(thread, callback)

[jkelaty-rbx]

Rendered

[MagmaBurnsV]

Would it be possible to instead return a status string detailing if the thread finished normally/failed/was cancelled, instead of a boolean? Or is this information lost after the thread is dead?

Because right now it's essentially impossible to differentiate between a closed thread and a thread that errored with the message "coroutine was closed".

[vegorov-rbx]

Might be a good idea, while a small departure from 'pcall' API, coroutine API is already richer with coroutine.status, so having "completed"/"cancelled"/"errored"

It does have a drawback of a bit harder distinction than if success then else end when you don't care about the 'fail' state details.
Also might need bikeshdding on what words are passed in.

[MagmaBurnsV]

It might be better to just error if the thread is already dead, since this behavior might lead to subtle bugs where you didn't expect the callback to run on the same thread.

You can still get this functionality back by checking the coroutine status and running the function inline, after all.

[vegorov-rbx]

Agree with MagmaBurnsV here, erroring here is much better.

It makes the whole system have less exceptions:

• you don't get states where results or errors have become unavailable
• callback is not called on a separate control-flow path, different environment from resume/close location might cause divergent behavior of the callback (on top of divergence caused by error not being recoverable)
• natively managed coroutine could have been reused, so patterns installing callbacks late have an extra footgun of installing on running coroutines that are logically different from the one before resume call on it

Coroutine is a lower level primitive, so I would not expect Promise semantics from it, but a promise can be built on top.

[MagmaBurnsV]

Can the callbacks yield? I assume not since other callbacks have to also run synchronously.

[vegorov-rbx]

I suggest that yes, callbacks can yield.

[Cooldude2606]

Overall I find this well written and a useful language level feature. However, silencing errors would be a deal breaker for me because it hinders not only debugging but also the detection of issues. For example, if most finally callbacks perform clean up actions then their failure may not introduce logical errors but rather memory leaks; which would be challenging to identify then trace back to the callback.

Propagating the error to the caller of resume or close would be preferable, which can be pcalled at that point if desired.

Although an alternative of replacing the status and message provided to proceeding callbackss could be a consideration. This would be similar to xpcall recalling the handler with its own error if the handler errors. But this would remove the ability to inspect the callstack through a custom xpcall error handler.

[bradsharp]

If finally provided the values that are still on the stack of the given thread it would allow you to implement await.

local function await(thread)
    local result = nil
    coroutine.finally(thread, function (...)
        result = table.pack(...)
    end)
    if not result then
        -- yield until the other thread has finished
        local current = coroutine.running()
        coroutine.finally(thread, function ()
            coroutine.resume(current)
        end)
        coroutine.yield()
    end
    local success = result[1]
    if not success then
        error(result[2])
    end
    return table.unpack(result, 2)
end

I don't think this needs to be perfect - the guarantee can be "whatever is left on the stack". A library can handle cases where the stack is later cleared by caching the result.

[vegorov-rbx]

I agree with Brad, it will be useful to provide results to coroutine callbacks and while thinking of the implementation path, I don't see a technical reason not to.

[bradsharp]

Is the callback allowed to yield? My initial reaction is no and we could always allow it later if we think it's okay.

[vegorov-rbx]

My suggestion is to include in the proposal that callbacks are allowed to yield.

Callbacks are not metamethods, so the restriction doesn't apply.
I see no technical/implementation reason to not allow it.
It will make the language library more flexible.

[alicesaidhi]

i think it'd be more ideal instead of returning a boolean, it'd return a string literal between "error", "finished", "cancelled"

[gaymeowing]

i think it'd be more ideal instead of returning a boolean, it'd return a string literal between "error", "finished", "cancelled"

Would be much better than giving a "coroutine was closed" string in the same spot the error argument is, as the error could be "coroutine was closed". This could be an issue for things like modding apis in games, or games that allow for using luau to do custom logic similar to Stormworks.

[vegorov-rbx]

This is an implementation detail, but weak-keyed table in the registry will not work when callbacks capture the thread.
Luau doesn't implement ephemeron tables so weak key still contains a strong value to that key.

In the actual implementation I will suggest storing a table inside lua_State.

[vegorov-rbx]

I will push back on this, discarding errors is not a good design decision.
I propose that errors will error

• coroutine.resume will return false with the produced error
• coroutine.close will return false with the produced error
  This has similarity with xpcall erroring on error handling, resulting in 'error in error handling'.

[vegorov-rbx]

Can we add a note that makes it error if called on VM main thread?
In many environments you can't even access it, so it's a small thing, but might save some C API user from confusion.