Boolean args should be allowed as flags on the command line

[Mortimerp9]

When an argument is a boolean, the presence of the --arg on the command line should be enough to infer true, it shouldn't be mandatory to write --arg true.
e.g.

class DoSchedule extends FieldArgs {
   var schedule = false
}

• with --schedule flag, set to true
• without the argument, set to false

[Mortimerp9]

I guess that this is not just at the level of the value parsing, but also the argument splitting.

[squito]

ehhh ... I've thought about this one before, but I'm not sure about it. The problem is, what to do when the default is true? I really don't want it to be a "toggle", b/c then you need to know what the default value is. And I don't like having a value which can only be turned on.

what do you think about automatically adding another "switch" style option, "--no-schedule" ??

[squito]

Lemme expand on my earlier comment.

1. I don't like the idea of the behavior changing based on the default values. Eg., I don't think the meaning of --schedule should change if the default in the code changes from false to true. This is especially important w/ multiple sources of defaults. Eg., what if its defaulted to true in code and false in the conf?? Personally, I think of the names & types as being the api. The defaults are not part of the api ... or at least, they are a much "weaker" part. They will change more often from deployment to deployment, or from the way the program is composed w/ other programs, etc. etc.
2. Here is a syntax I'm proposing that supports "switch"-style arguments, while still ignoring defaults. Every boolean argument var foo: Boolean = _ can be set 4 different ways:

--foo true   ---> set foo to true
--foo false  ---> set foo to false
--foo        ---> set foo to true
--no-foo     ---> set foo to false

The default value of foo is irrelevant in all cases. I think this is good b/c as long as the variable is named appropriately, the user is clear what they are doing in all cases. One downside is that if somebody happens to name their variable noFoo, then we end with --no-noFoo, but we could encourage the coder not to do that.

OTOH, I think this syntax will lead to some double negatives. Eg., an argument might be ignoreErrors. Then you get --ignoreErrors and --no-ignoreErrors. However, I think the meaning is still clear. --no-ignoreErrors means "set ignoreErrors to false (and do not ignore errors)". Of course, maybe even the coder will find a variable named ignoredErrors confusing in their code, and so might change the name to failOnErrors. Then you have --failOnErrors and --no-failOnErrors