[pigeon]: Support of modern asynchronous api for Swift and Kotlin

[feduke-nukem]

• Added support of generating modern asynchronous api for Swift (async) and Kotlin (suspend). New annotation @modernAsync
• Added ModernAsync annotation with SwiftModernAsynchronousOptions to specify if method throws

Resolves #123867, resolves #147283

Pre-launch Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the Tree Hygiene page, which explains my responsibilities.
• I read and followed the relevant style guides and ran the auto-formatter. (Unlike the flutter/flutter repo, the flutter/packages repo does use dart format.)
• I signed the CLA.
• The title of the PR starts with the name of the package surrounded by square brackets, e.g. [shared_preferences]
• I linked to at least one issue that this PR fixes in the description above.
• I updated pubspec.yaml with an appropriate new version according to the pub versioning philosophy, or this PR is exempt from version changes.
• I updated CHANGELOG.md to add a description of the change, following repository CHANGELOG style, or this PR is exempt from CHANGELOG changes.
• I updated/added relevant documentation (doc comments with ///).
• I added new tests to check the change I am making, or this PR is test-exempt.
• All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

[hellohuanlin]

you can just overload the function name func sendMessage(...)

[feduke-nukem]

I don't think that I understood.

It's generated Host API code. We could not overload functions in Dart even if we do in Swift

[hellohuanlin]

is this used for unit test? we shouldn't wait for so long as it slows down the tests

[feduke-nukem]

This is used in example app for demonstration purposes

I am not sure if it is used in any tests. I could remove this code if it is necessary

[feduke-nukem]

Removed Task.sleep

[hellohuanlin]

you can do Task { @MainActor } here.

[feduke-nukem]

you can do Task { @MainActor } here.

Do you mean:

            sendMessageModernAsyncChannel.setMessageHandler { message, reply in
                let args = message as! [Any?]
                let messageArg = args[0] as! MessageData
                Task {
                    do { @MainActor
                        let result = try await api.sendMessageModernAsync(message: messageArg)
                        reply(wrapResult(result))

                    } catch {
                        reply(wrapError(error))
                    }
                }
            }

Will it lead to executing api.sendMessageModernAsync on main thread that could block it?

[hellohuanlin]

No, i meant you can replace DispatchQueue.main.async {} with Task { @MainActor}

[feduke-nukem]

No, i meant you can replace DispatchQueue.main.async {} with Task { @MainActor}

What's the point/profit?

[hellohuanlin]

The purpose of swift concurrency is to replace GCD. So since you are using swift concurrency here, there's no reason to use GCD at all.

[feduke-nukem]

GCD

Okay I get it.

I am not very familiar with swift concurrency actually. Is that what you meant?

sendMessageModernAsyncChannel.setMessageHandler { message, reply in
    let args = message as! [Any?]
    let messageArg = args[0] as! MessageData
    Task {
        do {
            let result = try await api.sendMessageModernAsync(message: messageArg)

            await Task { @MainActor in
                reply(wrapResult(result))
            }

        } catch {
            await Task { @MainActor in
                reply(wrapError(error))
            }
        }
    }
}

Maybe we could use MainActor.run instead? I think it is more readable.

sendMessageModernAsyncChannel.setMessageHandler { message, reply in
    let args = message as! [Any?]
    let messageArg = args[0] as! MessageData
    Task {
        do {
            let result = try await api.sendMessageModernAsync(message: messageArg)

            await MainActor.run(){
                reply(wrapResult(result))
            }

        } catch {
            await MainActor.run(){
                reply(wrapError(error))
            }
        }
    }
}

[hellohuanlin]

In your first chunk of code, don't put await in front of Task.

For this particular case, you can use MainActor.run { ... }, since reply doesn't require an async context.

[feduke-nukem]

@hellohuanlin done

[hellohuanlin]

can we just reuse the channel?

[feduke-nukem]

How?

[hellohuanlin]

can you point me to where this is used? im wondering if you can just use the original channel

[feduke-nukem]

What do you mean by "original channel"? Each method of Host API got its own generated FlutterBasicMessageChannel.

This is default Pigeon generated code flow.

Maybe I've misunderstood you.

[hellohuanlin]

Maybe i misunderstood how pigeon is used. Just a strawman - can we share the same channel for both old and new ways of doing things?

[feduke-nukem]

The way we use channels will not differ at all either "new way" or "old". We just can not use two handlers for one channel at the same time.

[hellohuanlin]

Can we have old api to be the wrapper of the new api?

[feduke-nukem]

Could you provide code sample of what you mean?

[feduke-nukem]

@hellohuanlin @LouiseHsu @tarrinneal CI check fails:

Changed packages: pigeon
[0:00] Running for packages/pigeon...
  No version change.
  Found NEXT; validating next version in the CHANGELOG.
No version change found, but the change to this package could not be verified to be exempt
from version changes according to repository policy.
If this is a false positive, please comment in the PR to explain why the PR
is exempt, and add (or ask your reviewer to add) the "override: no versioning needed" label.

Do I need to bump version in CHANGELOG.md? Currently I append related to pr changes below NEXT label.