Comment by einpoklum
4 days ago
You need to remember _less_, rather than more, when you use this kind of vocabulary types. Think about std::optional. Before that (and if you didn't write something like it yourself), you had to, for each class, remember the bespoke semantics of when and how it represents the lack of some members, and you would have to have non-defaulted ctors, move assignments and dtors, and then whenever you used that class you would need to think about what those custom method do, which might be different than other classes which have optional members. Now you just tell yourself "oh, it just has an optional member, no biggie". Look at my comment above regarding how short the implementation of Widget becomes when you squeeze the juice from having the rule of 0.
No. This is not what I meant. I absolutely agree that std::indirect is an improvement. My point is that when dealing with C++ code, now there is yet another way of doing the same thing. I will have to remember both ways, because people will still keep using the old way.
Ok, well, you have a point, in that you might see the old way of doing things and you might see the new way. This is, however, one of the detriments of the language's commitment to backwards-compatibility: Old-C++ code is (almost without fail) valid new-C++ code.
When you write new code, this is (mostly) not an issue; when you have to maintain old code, it is. Especially if the existing codebase is somewhat of a patchwork of code introduced at different points in time - pre-C++98, C++98, C++03, C++11 and so on. For this reason it is a saintly virtue to manage to unify the C++ "vernacular" used in a project, for better readability by newcomers and for facilitating uniform changes to the entire codebase later on.