It made sense to me to raise this topic in the forum where a wider audience might weigh in before 0.18/1.0/whatever stabilizing might happen.
The basic issue is whether command users have to separate option keys from option values (e.g. with a ':' as the current code does). In order to avoid that requirement, command authors need to update a list of option keys whenever they change them which is a hassle. So, there is a tension between convenience to CLI authors and CLI users. As a user, I often forget to type the ':' and would be delighted if more people chose the symbol table route.
Myself, I think having an optional symbol table is the most programmer and user-friendly solution. That's what I did in parseopt3 in cligen. If the programmer wants to provide more POSIX-like command syntax then that's easy. OTOH, if like Araq they very understandably prefer not to have to update a symbol table when they add new option keys then they can just ignore that feature and make their users provide a ':' to separate option keys and option values. To me this kind of optional symbol table seems both backward compatible and forward looking and strikes a good balance for a stdlib.
I'm just one person, though, and that's just my opinion. The point of this thread is to solicit other opinions/perspectives/input to help figure out the best resolution of 6818 .
cligen looks very cool, I'll need to look into it.
I'm also curious how other people feel about the args situation. In my personal projects I've been using parseopt and having a user type ":" like the Nim Compiler...
To me this kind of optional symbol table seems both backward compatible and forward looking and strikes a good balance for a stdlib.
I have to admit, this is quite convincing. :-) Especially since it's just an addition to parseopt, breaking nothing, I hope.
It really shouldn't need to break anything, though mistakes can always be made in some initial pass. :-)
I would think you might also like long option key normalization so that one doesn't have to remember when typing commands --how-toSpell_OptKeys-exactly. Entering commands is often more ad hoc and personal than writing code, to the extent they are even distinct.
Also, if it matters, I'm happy to donate parseopt3.nim to the cause. That adds a few more features beyond optional symbols like "--"/stopWords, and optionNormalize. It should be API/backward compatible by default, but I really haven't tested it much outside being driven by cligen macros. E.g., I'm not sure how it fares against quoting issues that arose recently.