Komari Spaghetti

Are you able to provide compileable source code that reproduces this problem? That would make it a lot easier to debug.

Aah yikes. That is not intended. The question then becomes how to fix this. I don't really want to have diagnostics own memory if possible, but that might be what...

Sounds like a good idea. I can't promise I'll get around to implementing this myself though

Yea, that does seem worth while. I'm not sure it is something I'll really get to doing as I'm not using zig-clap that much myself anymore.

> What are you using then? If I may ask Currently, I'm testing out something simpler: https://github.com/Hejsil/dipm/blob/4b24131e2b010ef8577fb650ca39d2305e6b3b4e/src/ArgParser.zig Usage: https://github.com/Hejsil/dipm/blob/4b24131e2b010ef8577fb650ca39d2305e6b3b4e/src/main.zig#L125 I just have a copy of this file in a few...

It's not really something I want to bake into `parseParamsComptime` specifically. Seems pretty specific. Maybe in the future there is a function called `parseHelp` that parses an entire help message...

We probably don't need `@getNextGloballyIncrementingInteger()` for uniqueness, as that is what we have `@OpaqueType` for. We could probably pass `@OpaqueType` to `ComptimeAllocator.init` to ensure that all calls are never cashed...

This seems to be a bug in how buns fork of zig-clap handles errors. For long arguments, a warning might be printed, but then the error is ignored: https://github.com/oven-sh/bun/blob/main/src/deps/zig-clap/clap/streaming.zig#L105 For...

Yea, this currently does not work and I'm not entirely sure how I would make it work with now clap parses positionals. A PR to document this limitation is welcome....

If we are going this way, then there could be a case for not having `@Float`, `@Array` as these types can be constructed using comptime logic alone: ```zig /// @Float...