Command-line-api: Options without arguments are lost

[jnm2]

There doesn't appear to be a way to find out whether an option was specified unless you also add an argument. This program prints false whether or not --no-start is specified:

public sealed class Program
{
    public static Task<int> Main(string[] args)
    {
        var root = new RootCommand(handler: CommandHandler.Create((bool noStart) => Console.WriteLine(noStart)))
        {
            new Option("--no-start", "Explanation")
        };

        return root.InvokeAsync(args);
    }
}

This causes it to start working, but it also causes the help screen to show --no-start <NOSTART> instead of leaving it at the more desirable --no-start.

            new Option("--no-start", "Explanation", new Argument<bool>(defaultValue: false))

Usage:
  TestApp [options]

Options:
  --no-start <NO-START>    Explanation
  --version                Display version information

I don't know when I would ever want to see <NO-START>. If anything shows up for a flag option, it should be square brackets to indicate that flags don't require a value: --no-start [ true | false ].

But before we get that far, it really seems like the first program should work.

(Using 0.1.0-alpha-63902-01)

[jonsequitur]

The first issue looks like a binding bug.

We should also make the help output clearer for bool arguments, although in your initial code example, there's no clear way to infer the type of the argument.

[jnm2]

I was thinking that the fact that there is no argument could be used to infer that the option is a flag. If that's wrong, what does it mean to leave the argument null? That it will default to what the binder finds?

[jonsequitur]

System.CommandLine has both early binding and late binding behaviors, so it's possible to define an Option without specifying an Argument.ArgumentType. In this case, the binding to a type depends on what you ask it for.

The following code illustrates this behavior (which is working) and shows that the bug is in binding to a method parameter.

bool? received = null;

var root = new RootCommand(handler: CommandHandler.Create((bool noStart) => received = noStart))
            {
                new Option("--no-start", "Explanation"
                            // , argument: new Argument<bool>() // <-- Both assertions pass if you uncomment this
                    )
            };

var result = root.Parse("--no-start").ValueForOption<bool>("--no-start"); 

result.Should().BeTrue(); // <-- Passes

await root.InvokeAsync("--no-start ");

received.Should().Be(true); // <-- Fails (bug)

[jnm2]

I see. So passing null as the argument doesn't mean "this option will not be syntactically followed by an argument," i.e. the option is a simple flag, but rather "the argument will be late-bound." I wonder if this could be documented easily.

[jonsequitur]

@NextTurn That would be more expressive, but it's not supported since Argument.None isn't evaluated at compile time.

[jonsequitur]

So passing null as the argument doesn't mean "this option will not be syntactically followed by an argument," i.e. the option is a simple flag, but rather "the argument will be late-bound."

Correct. There are two different concepts in play here:

• Argument.Arity, which is the number of tokens that will be associated with an option or command at parse time, and
• Argument.ArgumentType, which is the .NET type that the argument is intended to be bound to.

By default, Arity is inferred based on ArgumentType, but they're allowed to differ to support custom binding.

We definitely need to make the API clearer here.