Re: argmatch: accept perfect matches in documented arglists

[Akim Demaille]

> Le 19 mai 2019 à 13:05, Bruno Haible <address@hidden> a écrit :
> 
> Hi Akim,
> 
>>>> +static const char *const backup_docs[] =
>>>> +{
>>>> +  N_("never make backups (even if --backup is given)"),
>>>> +  N_("make numbered backups"),
>>>> +  N_("numbered if numbered backups exist, simple otherwise"),
>>>> +  N_("always make simple backups"),
>>>> +  NULL
>>>> +};
>>>> +
>>>> +static const enum backup_type backup_doc_vals[] =
>>>> +{
>>>> +  no_backups,
>>>> +  simple_backups,
>>>> +  numbered_existing_backups,
>>>> +  numbered_backups
>>>> +};
>>> 
>>> This is hard to maintain. Better put things next to each other that
>>> belong together. Namely, can you put the enum value and each docstring
>>> into a single struct?
>>> 
>>>   { no_backups, N_("never make backups (even if --backup is given)") },
>>>   { simple_backups, N_("make numbered backups") },
>>>   { numbered_existing_backups, N_("numbered if numbered backups exist, 
>>> simple otherwise") },
>>>   { numbered_backups, N_("always make simple backups") },
>> 
>> Yes, of course, it would be nicer, but argmatch does not force the size of 
>> the values.  And I didn't want to force the user to provide an lvalue for 
>> each single value.  So I'm using the same approach as the rest of argmatch: 
>> pass a pointer to an array, and the size of the data.
>> 
>> We can provide another type restricted to ints for this common case though.
> 
> I can't really follow what you wrote here.
> 
> What I mean is that any facility where the programmer has to write two arrays
> filled with items that belong together, in a 1:1 correspondence, is 
> ill-designed.
> It is just too easy to update one of the arrays and forget about the other 
> one.

I am saying that the values (those in backup_doc_vals for instance) are not 
required to be ints.  I'm saying that in the example above backup_doc_vals are 
enums, but they could be floats, structs, chars, whatever.  So there cannot be 
a single type that would make it possible to write 

>>> { no_backups, N_("never make backups (even if --backup is given)") },
>>>   { simple_backups, N_("make numbered backups") },
>>>   { numbered_existing_backups, N_("numbered if numbered backups exist, 
>>> simple otherwise") },
>>>   { numbered_backups, N_("always make simple backups") },

Or are you suggesting that users should define their own type.  Or do you mean 
to provide a macro to instantiate such a type given a data type?  Or are you 
suggesting to restrict to a single size data type?