A small critique of your code (though it does seem to me the overall quality is decent): watch out for unintended ADL. You call lots of unqualified namespace-level functions (like load(...)). This triggers ADL, and it doesn't look like it's always intentional.
Oof... ADL scares me, but I don't know which load(...) you're referring to. src/serialize.cpp has a single such function call, am I supposed to avoid using the name `load` or qualify it with the namespace path (perhaps I shouldn't have nested namespaces so deeply, but I don't want to change it now)? Everything seemed to compile and work fine the last time I touched this codebase.
> Oof... ADL scares me, but I don't know which load(...) you're referring to. src/serialize.cpp has a single such function call
Yup that's the one I mentioned. It was just an example though, there are lots of others.
> am I supposed to avoid using the name `load` or qualify it with the namespace path
The latter. i.e. you should write serialize::load() (or ::serialize::load()) unless you intend ADL to occur.
> Everything seemed to compile and work fine the last time I touched this codebase.
Yeah I wasn't claiming it wouldn't compile right now. The problem is that it has a higher risk of changing behavior in the future. In this example, if this function is ever introduced:
namespace kj { auto load(InputStream &stream) { ... } }
then suddenly that function will get called instead of yours, which may or may not result in a compiler error.
It's not exactly the biggest footgun in C++, but "well-written" C++ code tries to be careful about pitfalls like these.
I want a language with the pragmatism of C++ rather than the "mutability excludes aliasing, no lifetime errors allowed, at the cost of usability, and no defined unsafe pointer semantics so far" unfinished experiment of Rust, with better sum type syntax than std::variant, and eliminating C++ footguns luke {implicit conversions, implicit copies, mixed-sign integer comparison, silently overriding virtual methods, C-style casts of multiple inheritance pointers is UB...}. Perhaps Cppfront holds promise, possibly Carbon or Jakt, maybe Zig though it lacks RAII when convenient and its return value semantics (much like Carbon's) is a footgun: https://github.com/ziglang/zig/issues/5973.
