Unfortunately this is a result of how types satisfy requirements when conforming to protocols in Swift. The ParsableCommand protocol has mutating func run() throws as a requirement, which can be satisfied by any of these:

func run() { ... }
mutating func run() { ... }
mutating func run() throws { ... }
func run() throws { ... }

...but not by a function with default parameters. Here's a stripped down example:

protocol Command {
  func run()
}

extension Command {
  func run() {
    print("Default implementation")
  }
}

struct Example: Command {
  func run(extraFast: Bool = true) {
    print("Example implementation")
  }
}

func runSomeCommand(_ command: some Command) {
  command.run()
}

func runExample(_ command: Example) {
  command.run()
}

let example = Example()
runExample(example)
runSomeCommand(example)
// Prints:
// Example implementation
// Default implementation

While the default-parametered Example.run() is callable on concrete instances of Example, it doesn't actually satisfy the Command.run() protocol requirement, so when .run() is called on an instance where the only thing known is its Command conformance (as in runSomeCommand(_:)), then the protocol's version is called. You can see this if you comment out extension Command { ... } -- without that, the compiler says:

- error: type 'Example' does not conform to protocol 'Command'

because Example doesn't provide a method that satisfies the protocol requirment.

In this case, my recommendation is to go the other way – leave the defaults off your custom method and provide them within your run() implementation, or use another method name:

struct FixedExample: Command {
  func fixedRun(extraFast: Bool = true) {
    print("FixedExample implementation")
  }

  func run() {
    fixedRun()
  }
}

runSomeCommand(FixedExample())
// Prints "FixedExample implementation"

@natecook1000 Thanks for the info. I haven't had a chance to look into the following, but could @_disfavoredOverload be useful at all for this circumstance? I'm not sure exactly how that interacts (or other possible similar attributes interact) with function selection…

FYI, when I dealt with this back then, I used your first suggestion: I didn't have defaults in my custom function, instead supplying the default values in my run() function implementation.