Work project has involved deep work within the ESP-IDF and a lot of C++ extensions, and alongside the code i'm developing... feelings.

ESP-IDF started out "hey, this isn't so bad" and "wow, they've done some clever things in here", but I think the honeymoon phase is over. We've run into SEVERAL nasty, fresh bugs in peripheral drivers. This chipset has been out a long time, how are they not really getting I2C right?!? Disconcertingly unstable given how much seems to be increasingly built on it.

And C++ extensions (C++20 and later)... This has been my first exposure to a lot of the stuff they've been adding to the C++ STL. Not sure i'm a fan of a lot of these design patterns. Probably half of what i'm butting heads against is probably my own resistance to change, but I really find the readability going out the window.

Pretty wild that i'm often needing to static_cast<std::underlying_type<ENUM>>(ENUM:VALUE). This, uh, used to be much simpler.

Also, for this example of a templated i2c register write function that works on scoped enums - I guess the most valid question here would be "why are we forcing scoped enums in the first place?" But also - why is the validation on whether or not the input enum is scoped occurring in the type signature of the return? That's weird, right?

I'm also torn because "auto" is both a convenience and a goddamn plague

Anyway, i'm very new to this, and I understand the general principle of adding layers of type safety, but boy howdy is it odd to read for the uninitiated