This is really cool (I&#x27;ve been wondering how to do a string-switch for a while now), but I don&#x27;t think getopt is a great use case, because getopt still results in imperative argument parsing and this always results in pain.<p>I&#x27;ve been working on libargs for the past year; it&#x27;s a declarative argument-parsing library for C: <a href="https:&#x2F;&#x2F;github.com&#x2F;mcinglis&#x2F;libargs" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;mcinglis&#x2F;libargs</a><p>The main idea is that each argument is by default parsed and stored as a string, or you can optionally specify a function of the type `void f(char * name, char * arg, void * dest)` to parse the argument string and store it in a well-typed destination. This way, you can have an `int` argument by passing `int__argparse` as the parser, and if the user passes a value outside the range of `int`, then an appropriate out-of-range error is printed to the console. Similarly with `uchar__argparse` or something like `point__argparse` (e.g. taking some format like `{x,y}`).<p>libargs is quite flexible and has worked well for me so far. Automatic help text generation can be added in future while maintaining (non-ABI) backwards compatibility.<p>The main disadvantage is that it depends on other libraries I&#x27;ve developed that are essentially Jinja-templated C source files that function as makeshift generic types &#x2F; typeclasses in C. Your inclination towards this approach depends on taste; personally I much prefer deferring the pain to the build system, as opposed to the source code.