On the topic of modules: a single-header template implementation is still the most practical and quick way to distribute a library. Module support is currently iffy - I wouldn't use them.
You've all made it very clear that from a user's perspective, a single-header library is still the gold standard for ease of use and integration. The ideal scenario is for a developer to just #include "binaryrpc.hpp" and have everything work without touching their build system, and I now see that as a crucial goal for the project. My framework isn't there yet, and the feedback has been a wake-up call that the current multi-header approach creates too much friction for new users.
So, my path forward is clear: 1. First, focus on simplifying the core API based on the initial feedback (e.g., creating wrapper objects for payloads). 2. Then, work towards providing a single-header distribution for maximum compatibility and ease of use.
I agree that modules are the future. But for now, delivering the most practical and frictionless developer experience seems to be the most important priority.
Thanks again for guiding me on this.
There’s effectively one developer working on module support in clangd. I have submitted more than one issue with minimal reproducible examples of hard clangd crashes and every one is still open or Ive given up on following them.
I’m all for modules myself and when you aren’t hitting the edge cases hey are absolutely amazing.