args: default negatable to false about args HOT 9 OPEN

<img src="https://avatars.githubusercontent.com/u/5449880?v=3" align="left" width="48" height="48"hspace="10"> Comment by iposva-google

In my opinion why you want negatable boolean options is so that you can easily experiment on the command line without having to remove the flag by just adding the "no-" to form a --no-xyz. It is especially useful if you want to call out that a flag is off when comparing two outcomes.

Also the premise that the default is set to false in general is not entirely correct. An example: The --inline flag should probably default to true in a compiler, with the option to turn off inlining if needed. A false default would mean that you would have the awkwardly named flag --dont_inline and the even more strange use within the code.

Added Area-Pkg, Library-Args, Triaged labels.

from args.

<img src="https://avatars.githubusercontent.com/u/444270?v=3" align="left" width="48" height="48"hspace="10"> Comment by seaneagan

Thanks, I wasn't aware of the use case to quickly switch between --foo and
--no-foo. And I do see how explicitly specifying what is already the
default can be helpful.

My main gripe though is that since I get a negated version by default, it's
easy to introduce non-sensical negated options, like --no-quiet or
--no-version, but then to remove them later is a potentially breaking
change. For flags that default to true, you could have only the negated
version, e.g. --no-inline, which makes it much more obvious that inlining
is the default behavior.

from args.

<img src="https://avatars.githubusercontent.com/u/444270?v=3" align="left" width="48" height="48"hspace="10"> Comment by seaneagan

FWIW, I looked up chrome's command line flags (since it has a ton of them):

http://peter.sh/experiments/chromium-command-line-switches/

and they seem to follow the practice of only including --no-foo, instead of
both, e.g. --[no-]foo

from args.

<img src="https://avatars.githubusercontent.com/u/444270?v=3" align="left" width="48" height="48"hspace="10"> Comment by seaneagan

Also forgot to mention that multiple flags are also often used in an enum
type way, where only one of the flags should ever be specified at a time,
for example see:

https://github.com/dart-lang/spark/blob/master/ide/tool/test_runner.dart#L129

.. and these type of flags are never negatable.

from args.

<img src="https://avatars.githubusercontent.com/u/3276024?v=3" align="left" width="48" height="48"hspace="10"> Comment by anders-sandholm

Removed Library-Args label.
Added Pkg-Args label.

from args.

<img src="https://avatars.githubusercontent.com/u/46275?v=3" align="left" width="48" height="48"hspace="10"> Comment by munificent

Yeah, I agree with you Sean. I thought defaulting to allow negation would make things more flexible, but in practice it feels like the wrong default.

Alas, it would be a breaking change. I'll probably do it at some point, but I'm going to sit on it for a while.

from args.

Another reason to have negatable flags is if the tool supports saving defaults (e.g. in a .xxxrc file). If you save a positive value, you need a way to negate it on the command line.

For this reason, --verbose and --quiet should indeed be negatable.

I think the real solution here is to make addCommand support taking commands that start with --. --version is really a weird special case, in arg's convention it really should be a command. Similarly with --help, in a way.

Though if --version and --help are the only special cases, then having them require negatable:false seems fine to me.

from args.

I think the real solution here is to make addCommand support taking commands that start with --.

Can you expand on this? I'm not 100% sure what you mean.

from args.

When you say "foo --version", you're really saying "foo version", that is, you're trying to run the "version" subcommand of "foo".

from args.