Supporting subcommands with same option name as reused parent command?

While working on this patch to fix help output to not show duplicates of options re-used throughout a command hierarchy...

I wondered what should happen if I tried to reuse the same option names in parent and subcommands. Consider this example...

struct Command: ParsableCommand {
  static var configuration = CommandConfiguration(
    subcommands: [Sub.self]
  )

  @Option()
  var arg: String

  struct Sub: ParsableCommand {

    @OptionGroup()
    var parent: Command

    @Option()
    var arg: String

    func run() throws {
      print(parent.arg, arg)
    }
  }
}

If I try to invoke this like so...

command --arg value1 sub --arg value2

...then it shows this error message...

Error: Missing one of: '--arg <arg>', '--arg <arg>'
Usage: command sub --arg <arg> --arg <arg>

The error itself is unhelpful and should be fixed, but let's ignore that for this discussion. I want to know what we expect this should do, both in the short and long terms.

When I first started poking around with subcommands, I assumed that parent command parameters brought into a subcommand would need to come before the subcommand in the line. @nnnnnnnn pointed out to me that this is not the case. We could easily call the above command example like so...

command sub --arg value1 --arg value2

Given that, it makes sense to me now why we wouldn't want to support "reusing" the same option name across a command hierarchy. It doesn't fit this model. But I figured I should bring this up and see if this is something intentional or not.

Terms of Service

Privacy Policy

Cookie Policy