Problem

We are using $inputOption->setDefault($value); to inject configuration settings into Symfony Console applications. The advantage of doing this is that the current configuration value is shown in the help output as the default value, and specifying a different value via an option on the commandline overrides the configuration value, as it should do.

However, if we call setDefault() on a boolean option, we get an error message.

Proposed solution

Some (non-Symfony-Console) commandline tools display option help like this:

    -i, --[no-]interactive           be interactive and colorful

The above example is from the Travis CLI tool.

A default value could be added to these for consistency:

    -i, --[no-]interactive           be interactive and colorful [default: --interactive]

Considerations for backwards compatibility

In order to preserve backwards compatibility, a new InputOption constant could be added to the existing set (InputOption::VALUE_NONE, InputOption::VALUE_REQUIRED, etc.) to enable the new behavior. Adding InputOption::VALUE_BINARY would be a drop-in replacement for InputOption::VALUE_NONE that would have the following effect:

• The help text for the option would be rendered as shown above.
• Setting a default value would now be allowed.
• The default value for the option would have to be boolean, and would throw if not.
• Input validation would automatically support a --no-foo option for any defined binary --foo. The result of supplying --no-foo would be to set the value of the --foo option to false.

The behavior of supplying --foo and --no-foo at the same time should be deterministic, but there are options on how this is handled. I might favor "last one wins", but throwing an exception would also be possible.

Requested action

We would like to know if a pull request related to this feature would be considered, and if so, would it be eligible for eventual release on the Symfony 3.x branch?