Support arrays and associative arrays

[BradleyChatha]

Unless there's any other ideas, they should function the same way as in Phobos' getopt.

Add special UDAs that tell JCLI how many arguments to dedicate to it.

[andrey-zherikov]

Users might want to specify some restrictions on how many values are expected: [min, max] range in general (not all combinations are useful for sure so this is just for illustration),

And I have few ideas on top of this:

• If target type is static array of size N (e.g. int[N]) then exactly N values are expected by default.
• If target type is dynamic/associative array then any number of values in [1, inf] range is allowed.
• By default at least one value is expected.
• There should a way to tell that no values are allowed.

So there should be:

• A way to tell that exact N values are expected, say @ArgExactNumberOfValues(N)
• A way to tell that no values are allowed, say @ArgZeroOrMoreValues(<value-if-nothing-provided>)
• A way to tell that at least one value is expected, say @ArgOneOrMoreValues()

In addition, this will be useful for other types:

• A way to tell that a value is optional, say @ArgOptionalValue(<value-if-nothing-provided>)

[BradleyChatha]

Users might want to specify some restrictions on how many values are expected: [min, max] range in general (not all combinations are useful for sure so this is just for illustration),

That's what validators are for. Maybe we could extend validators to allow them to add text into an arg's description if that's what you're thinking of?

If target type is static array of size N (e.g. int[N]) then exactly N values are expected by default. If target type is dynamic/associative array then any number of values in [1, inf] range is allowed. By default at least one value is expected.

All reasonable and I agree with.

There should a way to tell that no values are allowed.

Mark it optional, as with every other type of argument Nullable!(string[]) arg;

A way to tell that exact N values are expected, say @ArgExactNumberOfValues(N) A way to tell that no values are allowed, say @ArgZeroOrMoreValues() A way to tell that at least one value is expected, say @ArgOneOrMoreValues()

Again, validators. Unless there's special functionality that CommandLineInterface needs to special case, then these should be provided a built-in validators instead of special-cased UDAs.

A way to tell that a value is optional, say @ArgOptionalValue()

Nullable: Nullable.isNull, Nullable.get(default_value).

[andrey-zherikov]

Users might want to specify some restrictions on how many values are expected: [min, max] range in general (not all combinations are useful for sure so this is just for illustration),

That's what validators are for. Maybe we could extend validators to allow them to add text into an arg's description if that's what you're thinking of?

Not really. Validators are not able to tell how many elements to consume from the input (CLI args).

There should a way to tell that no values are allowed.

Mark it optional, as with every other type of argument Nullable!(string[]) arg;

There are three possible use cases, say for --foo argument:

• Argument is not provided in command line
• Argument is provided but without a value
• Argument is provided with a value

For example, -j option in make tool (syntax -j [jobs]):

• If there is no -j then is assumes 1 CPU (i.e. -j=1)
• If there is -j without a value then number of CPUs is unlimited
• If there is -j with a value then number of CPUs is set to specified value

A way to tell that exact N values are expected, say @ArgExactNumberOfValues(N) A way to tell that no values are allowed, say @ArgZeroOrMoreValues() A way to tell that at least one value is expected, say @ArgOneOrMoreValues()

Again, validators. Unless there's special functionality that CommandLineInterface needs to special case, then these should be provided a built-in validators instead of special-cased UDAs.

Can validators tell CommandLineInterface how many elements to get?

A way to tell that a value is optional, say @ArgOptionalValue()

Nullable: Nullable.isNull, Nullable.get(default_value).

See above: the value is optional, not argument itself

[BradleyChatha]

Not really. Validators are not able to tell how many elements to consume from the input (CLI args). Can validators tell CommandLineInterface how many elements to get?

It took me a moment, but I finally see what you're getting at. Ok yeah, we'd need to have special UDAs for that.

If there is no -j then is assumes 1 CPU (i.e. -j=1) If there is -j without a value then number of CPUs is unlimited If there is -j with a value then number of CPUs is set to specified value

Is this something standard between tools? IMO that's a pretty confusing design choice. It works for flags since it's rather standard behaviour, and there's a well defined set of values that are expected, but I feel arbitrary arguments like this case could be more a cause of frustration (for the user of the tool).

I'm pretty against that to be honest, I'd rather arguments either expect a value or they don't.

[andrey-zherikov]

Is this something standard between tools? IMO that's a pretty confusing design choice. It works for flags since it's rather standard behaviour, and there's a well defined set of values that are expected, but I feel arbitrary arguments like this case could be more a cause of frustration (for the user of the tool).

I wouldn't say that it's used in every tool but it's useful if user wants to enable some tool feature with default settings.

Here are some tools that do use this:

dmd:

• -HC[=[silent|verbose]]
• -i[=pattern]

grep:

• --color[=WHEN]

sed

• --in-place[=SUFFIX]

diff

• --context[=NUM]
• --unified[=NUM]

[BradleyChatha]

mm. We'll have to see how I feel about it in the future. So it's not written off completely, but I'd rather think and work on all the other stuff right now :o)