Jumping on the footgun bandwagon, one I had always known, but never realized how bad of a design decision it was was "the c++ rvalue lifetime disaster" [0]. The

Jumping on the footgun bandwagon, one I had always known, but never realized how bad of a design decision it was was "the c++ rvalue lifetime disaster" [0]. The talk linked in [0] has a different conclusion, but describes the problem well. Basically, the lifetime aspects of r/l-values are improperly coupled to the "can I scavenge the internals?" aspect (via const). R-values should not have been promoted to const-ref (I think it was a legacy behavior?) because then this const-ref can be passed around (e.g. returned) as if it were going to outlive the original reference's frame! This was the first time I realized what a mess C++ can be (although I still use it a lot). This is a subtle error that I have seen seasoned experts miss in code review (especially in templated code). You can't work around it like you can the underperforming parts of the stdlib (Abseil and Folly help out a lot!). This promotion choice of auto&& -> auto const& is really baked into the language and I don't see a path to change it. The other "biggest foot cannon" has gotta be the incredibly subtle ways one can violate the ABI, e.g. executable A linking against libs B and C, each of which bundle an ABI-incompatible implementation of the same parent dep D (versions 1.1 and 2.1). You never know which type of object you're really passing around with D::SomeType! [0] https://quuxplusone.github.io/blog/2020/03/04/rvalue-lifetime-disaster/ https://quuxplusone.github.io/blog/2020/03/04/rvalue-lifetim...