This was kind of an annoying change to make since 0.11.0 has issues
where it will point to the wrong srcloc on compile errors in generic
code (which this 100% is) fortunately fixed in master. The motivation
for this change is that the arg vector already contains 0-terminated
strings, so we can avoid a lot of copies. This makes forwarding
command-line arguments to C-functions that expect zero-terminated
strings much more straightforward, and they also automatically decay
to normal slices.
Unfortunately, environment variable values are NOT zero-terminated, so
they are currently copied with zero-termination. This seems to be the
fault of Windows/WASI, both of which already are performing
allocations (Windows to convert from UTF-16 to UTF-8, and WASI to get
a copy of the environment). By duplicating the std EnvMap
implementation, we could make a version that generates 0-terminated
env vars without extra copies, but I'll skip on doing that for now.
I think I still prefer snake_case stylistically, but this style fits in
a lot better with other zig code and is the officially endorsed style,
so it makes sense to use it. Since I don't have good test coverage,
some conversions may have been missed, but the demo still builds,
which is a decent amount of coverage. This was pretty easy to do with
a find and replace, so it should be reasonably thorough.
This is an interesting change. While I think generally passing in
constant userdata is not terribly useful, the previous implementation
precluded it entirely. Interface types, for example, are often passed
directly and stored as constants (they hold pointers to their mutable
state).
Since we type erase this so it can be bound to the generic interface
object, non-pointer objects must be passed by reference to avoid
binding the parser interface to a temporary stack copy of the object.
This means we have to handle these cases slightly differently. Also,
while technically being classified as pointers, slices don't really
behave like pointers, which is understandable but annoying. There's a
bit of asymmetry here, as CommandBuilder(*u32) and CommandBuilder
(u32) both require an *u32 when binding the parser interface. This is
of course because pointers do not need to be rewrapped to be type
erased. The same code path could be used for both cases, but then the
user would have to pass in a pointer to a pointer, which actually
looks a bit silly because then it potentially means having to
do &&my_var.
This needs a bit more thought. To support outside-in error writing,
converters need access to an allocator so they can create new buffer
writers. This can be done by passing in a pointer to an ArrayList
object directly, rather than an already bound writer.
I am resisting the urge to try to codegolf this into fewer lines. It's
going to end up being a sprawl, but it is what it is. The main part of
this that will actually require intelligent thought is the column
wrapping and alignment. I think I will probably be implementing a
custom writer style thing to handle that.
There are a lot of annoying loose odds and ends here. Choice types
should list all the choices. But we can't necessarily assume that an
enum-typed parameter is a choice type (only if it uses the default
converter). Perhaps the conversion stuff should be turned into an
interface that can also be responsible for converting the default
value and providing additional information. For now I will probably
just hack it so that I can move on to other things.
the checklist of things to do is continuing to dwindle. hooray. last
big feature push is help text generation. Then improving error
reporting. Then writing some tests. Then writing documentation.
Ay carumba.
The converters are hooked up, including some weird magic under the hood
to automatically handle multi-values as well as the many-to-one case
of the structure. The many-to-many case of arrays/slices is not
currently handled, but it should be straightforward to do.
Hooking up subcommands should be pretty straightforward if I've
designed this correctly, so that will be next. The final major piece
of the puzzle is help text generation, which in theory can be largely
carried over from the old implementation.
The error handling is very poorly done right now as well, and I need to
figure out a strategy. My plan for converters is to pass in a writable
buffer that the parser owns that they can write messages to when they
fail, to provide useful context. I will need to figure out how this
works for recursive converters (e.g. the struct converter) since the
failure happens inside-out, but the error message will read much
better if it's composed outside-in. There are many ways to tackle this.
The code will also need to be restructured to not be a monolithic 1000
line file.
Had to refactor the multi-value parameter stuff to push some of the key
information in to the generics structure, as they necessarily change
the conversion function signature. Some code has gotten folded
together by being a bit sloppier with inputs and outputs.
This should put us well on our way to having functioning value
conversion, which I think is the main major feature remaining besides
help text generation. Hopefully I won't need to rewrite everything
like this again. While this design seems to be on track to incorporate
all of the main features I am interested in, it has been a lot of work
to wrangle it around, and there is still a lot of work left before I
can put a bow on it.
Also work on a generic runtime parser interface for attaching
subcommands. This will allow subcommands to live in a mapping or
something at runtime which will simplify their use.
This is basically a full rewrite but with a much more solid concept of
what the public API looks like, which has informed some of the
lower-level decisions. This is not at feature parity with the main
branch yet, but it does handle some things better. The main
functionality missing is the help text generation and subcommands.
There's still some design to think about on the subcommand side of
things.
