Add AsyncParsableArguments to support validating async arguments

[luispadron]

Currently to share arguments across commands you can create a ParsableArguments type which contains your arguments/options, and can use func validate() throws to validate the arguments.

This fails for things that must be validated in an async manner. We should consider adding an async API for validating or AsyncParsableArguments to support this.

[CrazyFanFan]

I just encountered the same problem.

[dcantah]

Also just hit this.. thought I might've been holding it wrong. I can try and take a look

[natecook1000]

Given the headaches and challenges around supporting the sync and async versions of run(), I'm reticent to provide another overload here. As a workaround, you can perform any async validation at the start of your async run() method – if you throw a ValidationError from there you'll get the same output as an error thrown from the validate() method.

If this workaround doesn't work for you, please let me know!

[luispadron]

Yeah that works and it's what we do today but it lacks a few things:

• the argument cannot have the correct type, because the async function is not supported. E.g we need to declare the argument as String for example and then validate it converts to whatever type we wanted.
• this conversion needs to happen in all the commands which use that argument.

[ffried]

I'd like to throw another use case into the ring here:

struct PathBased {
    static func setup(withPath path: String?) async throws { /* ... */ }
}

@main
struct MainCommand: AsyncParsableCommand {
    static var configuration: CommandConfiguration {
        .init(subcommands: [
            SubCommand1.self,
        ])
    }

    @Option
    var somePath: String?

    func validate() throws {
         try await PathBased.setup(withPath: somePath) // error: 'async' call in a function that does not support concurrency 
    }
}

struct SubCommand1: AsyncParsableCommand {
   public static var configuration: CommandConfiguration {
        .init(commandName: "sub1")
    }

   public func run() async throws {
      // No way to call `PathBased.setup(withPath:)` b/c there's no way to access `MainCommand.somePath` here.
   }
}

It's of course possible to extract the somePath option into a ParsableArguments / OptionGroup sub-structure, but for one option it seems overkill.

Update / correction: It seems with #802 this is indeed possible. Still creates bidirectional explicit linking for something that could work out of the box.

[bhab20476-prog]

هاي في الثلاثاء، ٣٠ أيلول ٢٠٢٥ ١٠:٤٠ ص Florian ***@***.***> كتب:

…

*ffried* left a comment (apple/swift-argument-parser#630) <#630 (comment)> I'd like to throw another use case into the ring here: struct PathBased { static func setup(withPath path: String?) async throws { /* ... */ }} @mainstruct MainCommand: AsyncParsableCommand { static var configuration: CommandConfiguration { .init(subcommands: [ SubCommand1.self, ]) } @option var somePath: String? func validate() throws { try await PathBased.setup(withPath: somePath) // error: 'async' call in a function that does not support concurrency }} struct SubCommand1: AsyncParsableCommand { public static var configuration: CommandConfiguration { .init(commandName: "sub1") } public func run() async throws { // No way to call `PathBased.setup(withPath:)` b/c there's no way to access `MainCommand.somePath` here. }} It's of course possible to extract the somePath option into a ParsableArguments sub-structure, but for one option it seems overkill. — Reply to this email directly, view it on GitHub <#630 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BYB4MMRPDLLRXD2ZORQEGOT3VIXYLAVCNFSM6AAAAACH3YU6FWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTGNJQGQZTAMJUGE> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>