Document that suspend fun invoke() becomes __invoke() in Swift

[chrisbanes]

We make heavy usage of suspending invoke functions, like:

interface FooInteractor {
    suspend operator fun invoke(): Foo
}

These allows us to implement certain actions/interactions 'natively' on each platform. Without SKIE, these interfaces can be implemented in Swift like so:

class IosFooInteractor: FooInteractor {
    func invoke() async throws -> Foo {
        // todo
    }
}

With SKIE, Xcode wouldn't compile and it took me a while to workout that the function name is now called __invoke() in Swift, rather than invoke(). I'm sure there's a reason for this (similar to enums), but it would be handy if this was documented.

[FilipDolnik]

Hi! Sorry about that. I was pretty sure this behavior was documented, but now I can't find where. The documentation underwent multiple revisions, so it must have been removed by accident.

You are correct that the prefix is there for a reason similar to enums - avoiding name collisions with the generated code. The wrapper async function is an extension, so it's not possible to override it directly. Therefore, we can't just remove the original function; instead, we change its name so that it's still possible to override it.

[chrisbanes]

No worries! I guessed that was the case 😃

[TadeasKriz]

@chrisbanes Do you normally implement the async throws or the callback one? And if it's the async throws, do you use Swift's await in there?

I'm asking because we have a prototype where the prefix isn't added, but the only available variant is the one with callback (because we disable the automatic async conversion from ObjC). So if you implement the async throws, that wouldn't really help.

Additionally, if you use any await in there, keep in mind that cancellation is not supported inside these methods (with your experience I'm sure you know that already, but I wanted to mention it regardless for other folks who might read this).

[chrisbanes]

We normally implement the async throws version, and yes we use await. Is there a benefit to turning off the automatic async conversion? I don't mind implementing the callback version, but I'd prefer the compiler to do it for me 😅.

Re: cancellation. Yep, luckily the only use cases for these we've found so far are mostly fire-and-forget type scenarios.

[TadeasKriz]

IIRC, without turning off the async throws conversion it's ambiguous with the SKIE-generated async functions, so the prefix couldn't be removed in that case.

Thanks for those details, I think that just documenting this properly and keeping the __ prefix is the right way forward. Otherwise you'd lose the ability to decide if you want to implement the callback or async throws variant.

[chrisbanes]

Yep, that sounds like the correct path to me!

[FilipDolnik]

I added a mention about this use case to the documentation: https://skie.touchlab.co/features/suspend#overriding-suspend-functions