On 10/13/21 11:50 AM, Andrey Zherikov wrote:
> On Wednesday, 13 October 2021 at 14:36:30 UTC, Steven Schveighoffer wrote:
> One nitpick -- you should be able to opt in using the name of the field member instead of having to write @NamedArgument
. e.g. your string unused
parameter requires a @NamedArgument("unused")
which seems unnecessary.
I think unused
word confuses a bit. I meant the argument that is skipped in command line so it has a default value ("some default value"
).
So having this is totally fine:
struct Params
{
string s;
@NamedArgument("num")
int n;
}
I'll rename unused
to remove this confusion.
No, it's not a confusion about unused
. The array
parameter has the same issue.
I meant that for named parameters, one shouldn't have to attribute them for them to be considered part of the parameters.
e.g. (to replace your current code):
struct Params
{
// Positional arguments are required by default
@PositionalArgument(0) // override the default of a named argument
string name;
// Named argments are optional by default
string unused = "some default value";
// Numeric types are converted automatically
int num;
// Boolean flags are supported
bool flag;
// Enums are also supported
enum Enum { unset, foo, boo };
@NamedArgument("enum") // required since enum is a keyword
Enum enumValue;
// Use array to store multiple values
int[] array;
// Callback with no args (flag)
void cb() {}
// Callback with single value
void cb1(string value) { assert(value == "cb-value"); }
// Callback with zero or more values
void cb2(string[] value) { assert(value == ["cb-v1","cb-v2"]); }
}
The point is that I shouldn't have to tell the library the name of something that I've already given a name to.
Having them named differently on the command line than the actual field name should still be a possibility (and required in some cases, e.g. the enum
case above), but honestly, the Params
struct exists solely to accept command line parameters, there's no compelling need to use alternate names for the command line and the field name. If the library automatically does the right thing by default, then your code becomes simpler and more beautiful.
Not to detract from your library, because I think it's an awesome design to model using structs (one I use all the time), but the API developer in me frowns at lack of DRY. Try to focus on requiring the smallest amount of machinery/attributes possible. Every time you require extraneous pieces to get things to work, it adds another place where errors/confusion can happen.
-Steve