Hacker News new | ask | show | jobs
by Maxatar 786 days ago
I used to do this back when C++11 came out and ended up regretting it. When a feature just comes out, you can understand it possibly in isolation, but it's very hard to understand how that feature will fit in with other features, tools, libraries etc... and so you use it in a certain way according to how various blog posts and thought leaders say you should use it, and then after a year you end up realizing that no one could anticipate that the new feature has all kinds of footguns and certain features even end up being deprecated or superseded by yet another new feature.

When a new feature comes out, it's best to let it settle in a bit, maybe experiment using it on smaller side projects, but avoid diving into using it too early before it's really well understood.

For example I now cringe every time I see the curly bracket initialization of the form T{...} and how that was advocated as the one true way to initialize everything in C++, only for everyone to realize a year later that it has its own footguns (like with initialize lists) and with C++20 fixing almost all of the original problems that led to T{...}, the best practice nowadays is to go back to just using plain old T(...) and there's little to no reason to use T{...} anymore.

There was also Herb Sutter's Always Use Auto, which then was revised to Almost Always Use Auto, and now I think most developers take the sensible approach of use auto for redundant names like iterators, or unnamable types like lambda expressions, and avoid using it everywhere so as to turn your codebase into an opaque soup of inscrutable keywords.