speaking for myself here, but I don't think the (main) concern of the 'keep
cfg' camp is that the syntax is different between \--hint[LineTooLong]=off
(cfg) and hint("LineTooLong", "on") (nims) as that's easy to switch to (and we
can write a tool to automate if needed), their main concern is they want to be
able to enforce a purely declarative config in some cases (eg enterprisey,
whatever that means).
So I don't think we need to go out of our way to reverse engineer a type system
that would give a meaning to what is originally a command line syntax
hint[LineTooLong]=off, clang.cpp.options.linker etc. If anything, it'd be
better to provide a helper macro or helper proc that parses these from a
string, usable in config.nims:
config.nims:
parseFlags("""
--hint[LineTooLong]=off
--clang.cpp.options.linker
""")
Run
that seems much less contrived.
Also your approach, while cute on the surface, faces real technical issues:
* for better (or IMO for worse), the \--foo.bar syntax is un-constrained (see
[https://github.com/nim-lang/Nim/pull/8757#issuecomment-417781883](https://github.com/nim-lang/Nim/pull/8757#issuecomment-417781883))
so it's impossible to map a type hierarchy to it.
* for flags without arguments, eg \--embedsrc you'd have to latch on
parenthesis with your syntax eg:
embedsrc()
Run
which is ugly
* also not sure about how you'd map this: define:SYMBOL:VAL
# instead
ScriptMode:Declarative seems like a better way to satisfy the "keep cfg" camp.
