Fix for @Option(transform:) with optional type

[natecook1000]

Due to the restructuring in #477, there was ambiguity between the unconstrained @Option initializer that uses a transform (but no initial value) and the one that is constrained to the property being optional. This marks the unconstrained version as disfavored, which allows overload resolution to select the optional version when appropriate.

Fixes #618.

Checklist

• I've added at least one test that validates that my change is working, if appropriate
• I've followed the code style of the rest of the project
• I've read the Contribution Guidelines
• I've updated the documentation if necessary

[natecook1000]

@swift-ci Please test

[Coeur]

Thank you Nate.
To be exhaustive, we also need to fix Argument.swift by adding @_disfavoredOverload line 417, and add the same test replacing @Option with @Argument.

[rauhul]

Thanks for the fix! I would've expected the previous tests I added to catch this

[natecook1000]

@swift-ci Please test

[Coeur]

Question: to facilitate the understanding of the documentation, should we make such below changes too?

Option.swift, Line 508, change:

  /// var foo: String = "bar"

To:

  /// var foo: String? = "bar"

Option.swift, Line 577, change:

  /// var foo: String

To:

  /// var foo: String?

[natecook1000]

@swift-ci Please test

[Coeur]

The rename from foo to name may add to confusion, since there is also a name parameter in the initializer.

I suggested using title like in previous example.

[Coeur]

In general, maybe yes. But it would also work with non-nil default, like:

var char: Character? = " "

The fact that it's a mutable optional would then allow it to eventually become nil later in time (when a program wants to free some memory for instance).

[natecook1000]

That way of declaring (optional with a non-nil default) ends up using a different initializer that has a deprecation warning, since the behavior usually isn't what the author intends. I hadn't considered the use case you're describing here, but in general the ArgumentParser API is designed to essentially provide a way to write a function interface via the command line; the type declarations should match the CL interface.

[Coeur]

nit, plural: char -> chars

Same thing on lines 748 and 796

[natecook1000]

@swift-ci Please test