Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

args: default negatable to false #16022

Closed
DartBot opened this issue Jan 10, 2014 · 7 comments
Closed

args: default negatable to false #16022

DartBot opened this issue Jan 10, 2014 · 7 comments
Labels
area-pkg Used for miscellaneous pkg/ packages not associated with specific area- teams.

Comments

@DartBot
Copy link

DartBot commented Jan 10, 2014

This issue was originally filed by @seaneagan


I can't prove this, but I feel like non-negatable is more common.

For example, --help, --verbose, --quiet, --version are all non-negatable. Also, since flags should generally default to false, specifying --no-foo is redundant. I would prefer to explicitly ask for this feature when I need it, but I'm not sure when that would be.

@iposva-google
Copy link
Contributor

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.

@DartBot
Copy link
Author

DartBot commented Jan 13, 2014

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.

@DartBot
Copy link
Author

DartBot commented Jan 13, 2014

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

@DartBot
Copy link
Author

DartBot commented Jan 13, 2014

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.

@anders-sandholm
Copy link
Contributor

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

@munificent
Copy link
Member

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.

@DartBot DartBot added Type-Defect area-pkg Used for miscellaneous pkg/ packages not associated with specific area- teams. labels Jul 2, 2014
@DartBot
Copy link
Author

DartBot commented Jun 5, 2015

This issue has been moved to dart-lang/core#124.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-pkg Used for miscellaneous pkg/ packages not associated with specific area- teams.
Projects
None yet
Development

No branches or pull requests

5 participants