So, there have been various on again/off again conversations on github about
how the stdlib parseopt could/should behave. Those conversations seemed to have
a pretty narrow audience..basically participants on these github issue threads:
[4620](https://github.com/nim-lang/Nim/issues/4620)
[6818](https://github.com/nim-lang/Nim/issues/6818) .
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](https://github.com/c-blake/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](https://github.com/nim-lang/Nim/issues/6818) .
