I’ve been asked for examples so here is a shot, although I am sure the list could become even longer if I spent more time to think about it (and I’m sure many p

I’ve been asked for examples so here is a shot, although I am sure the list could become even longer if I spent more time to think about it (and I’m sure many people have thought about this): - Localized text doesn’t work with "iostream" sequences because one language says "A foo B" and another "B bar A". The entire concept of a sequencer like "<<" was wrong from the beginning but they kept it. All I really expect is a formatting method that accepts tuples. Apple made object formats work in Objective-C simply by adding "%@", and they have a solution for internationalization by embedding numeric order. - Not only are stream operators awkward to use but they are awkward and vague when customized. For years, until compilers basically hacked in ways to inline "friend" functions, you had to put the entire implementations for these operators in inconvenient places outside of classes. And what does it even mean to "operator <<" an object? For many classes, there are at least two useful streamed-out interpretations: a literal version of the object’s primary value(s) from the user’s viewpoint, and a full state representation for developers. The C++ standard library manages to create a very complex way to do something that is not even sufficient!! Many languages and environments have ways to generate multiple object representations. C++ should deprecate "operator <<" and create more grep-able functions that can produce variations (e.g. std::print_obj<T>(std::ostream&, T&) and std::print_debug<T>(std::ostream&, T&), where a default template implements the 2nd using the 1st). - The "iostream" classes are full of poorly named/located things. Often there are duplicate values with similar names so you have to remember which goes where and hope mistakes don’t compile (e.g. "f << std::hex" and "f << std::ios::hex" are completely different but the compiler allows both). And heck, "good()" does not have the exact opposite meaning of "bad()"! To this day, I see people screwing up and not handling edge-case stream failures correctly; that is an insane problem to have in a widespread standard class that every programmer should be able to learn correctly (and hasn’t, because the class has so many quirks). - As others have said, std::string lacks practical international support for sources like UTF-8 (which is ironic considering how the class template tried so hard to be adaptable for whatever they thought strings might need). And std::string does not have any really useful methods, especially after considering internationalization. I would say the least useful feature of std::string is size variance; I would hope for a new UTF-8-only class that just expects to be bytes, using good ideas from modern environments to present views of those bytes to programmers. - STL algorithms probably should not have been implemented in terms of iterators. For instance, if someone writes a template on "container", "container.find(x)" will not work for both sets and vectors; since "find(container.begin(), container.end(), x)" technically compiles with both, a naive programmer may choose to force that approach in every case and incur unnecessary O(n) complexities. Systems are typically so layered with generics that you cannot possibly know if this type of mistaken slowdown has been forced into your code. Assuming you want anything generic at all here, what you really need in the standard is something of the form "find(container, x)" so there is at least a chance for optimal behavior within the magic. - Ultimately, I wish that more of standard C++ would simply build on or improve standard C. The core C functions should be first-class, with object-oriented peanut-buttering added later where useful instead of baking functionality only into awkward classes that are found later to have design flaws. Even if the C++ version wants to take advantage of C++ "inline" or std::function<>, etc. it should still start as a function and work toward a class. Functions would also create more opportunities to get away from this insane syntax prediction problem that templates have, where you don’t really know if "x.f()" or "f(x)" is required (or if both are available, or worse if they do different things).