Ye, I know.
It basically requires resolving the sizes to code spans and then tracking diffs of those code spans over time.
(Or at least that would be how I would try to solve it)

I kinda feel LLVM should have something like that...
Like IIRC they had some test coverage tooling, which implies that there is infrastructure to connect compilation input <-> compilation output, which *should* be able to be used for getting info about code size.

Turing complete? Yes, definitely!
But defined in a specific language? No.

Instead the configuration should be defined via a protocol, which lets the client (the configurator) send requests to the server (the thing that is being configured) and lets the server send back events.

Users could then simply decide whether they want to go the `program path/to/config` or the `program path/to/socket` route.
(Or even record the configuration sequence and reuse it as static configuration)

*Ideally* the protocol should be possible to use non-interactively as well, so that you can just write the messages to a file and configure the program from that.

Which should be not *too* hard if the protocol is deterministic and doesn't have any timing based requirements...

Turing complete? Yes, definitely!
But defined in a specific language? No.

Instead the configuration should be defined via a protocol, which lets the client (the configurator) send requests to the server (the thing that is being configured) and lets the server send back events.

As context I am doing some codegen some wayland protocol things and `wl_display::get_registry {}` feels WAY more natural than having to PascalCase them.

What if I write my *type*-names in snake case...

Oooh! Every good story starts with some random MacOS syscall!

Completeness is really one of the most powerful concepts that rust has to offer.

Having problems actually SOLVED is an incredibly powerful for clearing your mind and focusing on your new projects!