Roadmap to support AVR/8-bit chipset

[antonysigma]

(Summarizing the discussions at #105 ... Please feel free to revise the roadmap below.)

1. Wait for ISO C++26 standard to publish, which requires the standard library <stdexcept> to be part of the freestanding C++ toolchain;
2. Work with team behind the project avr-libstdcpp to include a subset of <stdexcept> features. https://github.com/modm-io/avr-libstdcpp?tab=readme-ov-file#notable-adaptions-and-limitations
3. If step 2 is blocked, convince the fmtlib team to remove the line #include <stdexcept> in the header-only library, or make it an optional #include similar to how #include <fmt/compile.h> is made optional.
4. If step 2 and 3 are blocked, convince the compile-time-init team to make #include <fmt/format.h> optional.
5. If step 2, 3, and 4 are all "no go", the feature is clearly stuck in a multi-team, multi-project stalemate. maybe we should give up on Microchip/Atmel AVR chipset support in the compile-time-init framework. (After all, the limited 16-bit address space, and the Harvard architecture may not justify cib's complexity.)
6. Or, use an outdated version without the latest features, e.g. RLE encoding of the command router, i.e. right before 🎨 Change format to use fmtlib compile-time formatting #338 .

[elbeno]

👍

IMO we are in the middle of a re-reckoning for the avr-libstdcpp claim "Some parts of the C++ standard library are not well suited for tiny bare-metal systems." It may still be true, but to a much lesser extent given the amount of stuff that is becoming usable purely at compile-time.

We don't really have to wait for C++26 for avr-libstdcpp to implement <string> (given std::string is usable constexpr in C++20) and once you have <string>, <stdexcept> needn't be far behind.

[bdeane-intel]

Update: https://wg21.link/p3295 is currently targeting C++29.