Don’t blindly prefer emplace_back to push_back

All the simple names and most of the syntax were taken in C++98. This is one of the problems with backwards compatibility: even if everyone migrates to the new standard on its first day, so you never actually have to target the old compiler, the simplest way to do things will often be the old way.

Also, in mitigation, it's not a special-purpose word for appending to vectors. They introduced "emplace" to other STL data structures at the same time, with the equivalent semantics, so it's a word you only have to learn once.

I mean, this is entirely a self-inflicted problem. If you'd just use a few more words in the name, none of this would be an issue.

There's nothing wrong with longer function names. They make code a lot easier to read.

You'd prefer something like vec.construct_then_push_back(foo, bar)? I think it's reasonable that people would want a pithier name than that, for something you're going to use constantly.

"f8" would be even shorter, but we don't use that, because it is more important that code is easy to read than quick to write.

Actually, for frequently used standard library functionality, I would very much object to introducing overhead for educational purposes at every single call site.

It's a tradeoff, of course, but if the user code becomes unreadable because the function names are verbose (so you constantly have to wrap lines and cut through the visual noise to see the actually meaningful part of the code), just to make sure people don't misunderstand basic functionality... that's not the tradeoff I would like.

I think they mean `std::vector::construct_back_in_place()`. 200 character line widths will no longer be enough: 400 or 500 will be more realistic. Sacrifice readability for readability.

How many function calls do you put on a single line? Break those statements up!