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.

This comment was originally written 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.

This comment was originally written 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

This comment was originally written 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.

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

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.

This issue has been moved to dart-lang/args#26.