The wheels of the standards committee, I have said more than once, do grind slowly, but exceedingly fine. Apologies to probably Longfellow, though I might be mistaken. Anyway, progress continues on the next version of the standard and there are some details still to settle. Anthony Williams has written a nice summary of the October Mailing (in preparation for a November Meeting) along with some helpful links. He points out that generating move constructors (as compilers do today for copy constructors), as required by the Final Committee Draft (FCD) could break some existing code, so discussions are planned on restricting (or dropping) this implicit generation. I  like knowing that people are putting this level of thought into language changes instead of just issuing a Breaking Changes list and expecting me to go edit my code accordingly.

He also highlights situations where people are deliberately throwing exceptions from a destructor (gasp! I know!) and their working code will break unless they change it say they intend to throw exceptions from their destructor. You would think that this was a tiny population of people, and that marking their code in this way is no big deal, but C++ philosophy is that working code with defined behaviour should continue to be working code with defined behaviour in the latest version of the language. As you can see, that can really be a challenge sometimes.

If you're a C++ person, I challenge you to read the papers Anthony links to. If you can't understand a word of them, you're missing a lot of what C++ is these days. While talk of "implicit invariants", rvalues, and a "throwing move" may take some effort to decipher, I think it's worthwhile. C++ is a language in which performance and correctness are both paramount. That's why the developers are expected to manage lifetimes themselves, explicitly state whether they want shallow or deep copies, and so on. Template libraries simplify much of this (shared_ptr and unique_ptr are the death knell for the characters d-e-l-e-t-e in my code) but understanding those lifetime issues, understanding rvalues and lvalues, understanding when temporaries are created and deleted are all fundamental to being a C++ developer. Understanding those things lets you write better C++ code than you otherwise would. I know there are other languages in which your understanding doesn't matter because it is always done the same way. I also know that the control offered by C++ enables performance gains in specific situations where the developer knows better. These things can both be true at once, and can make other languages a better fit for certain developers or for certain business problems. They are also what makes C++ a better fit for some developers and some business problems. But if you don't have those understandings, if you don't want to control your application at that level, then why are you using C++? Use something simpler that can't be controlled the way C++ can.

For those who are using C++ "on purpose", who are "unrepentant" as I say in other of my talks, knowing the language at this level is key to being good at it. Would you say that "Implicit Move Must Go" or not?

Kate