There are many libraries that pass this rather low bar. You are not saying that all such libraries qualify for standardization, are you? What, ASIO is way too good, we can't expect this sort of excellence from any other library poised to become standardized?> How about this bar: for a library to qualify for standardization, it must have retained its dominant position for at least two years without any interface changes. To argue that this is unreasonable is equivalent to stating that there is nothing wrong with changing the interface after standardization.
I'm not unsympathetic to this viewpoint. I've often said that nobody should be standardising libraries which the committee invents out of thin air, yet the committee keeps doing exactly that. But I also think that "dominant position" is very hard nowadays. Most of the libraries which are dominant are designed around ancient C++. They have zero chance of standardisation. There is also the hard reality that even if your library has been stable for years, even decades, the committee is going to force you to completely redesign it into something totally innovative anyway. This is exactly what has happened to ASIO, the Networking TS will be getting close to a brand new design, a whole new API by the time its done. Or, better worded, it was redesigned by committee through invention out of thin air. That suggests to not go too far down the market share route first if your end goal is standardisation. That's simply facts on the ground, that's the playing field, and you have to play the game that is being played.
Nobody is arguing that they are not good. There is no reason to standardize every good library out there. We should only standardize the ones that have already become THE standard in their respective domain.
Equally, I think most would agree that iostreams needs an overhaul for modern C++. There is a ton of inefficiency in there, and moreover because the language lacks understanding of stuff like i/o, the optimiser mostly gives up when faced with trivially obvious i/o optimisation opportunities. This is very low hanging fruit, and it is stuff WG14 are not against also changing for C. POSIX is also keen. It just needs someone to do the work, coordinate the various parties, and get a common proposal over the line. I agree that it would be far better if multinationals sponsored this kind of deep in-out refactoring through prototype implementation. But they see no commercial advantage. For example, Microsoft is very well aware that Linux file i/o is up to 80x faster than Windows' now. It's getting embarrassing the difference. But Microsoft management can't see how closing the gap turns into extra dollars, so they won't authorise the works needed. They take the view that the customer will adapt if they need to. Meanwhile, all Windows users make do with awful git performance, and much slower compile times. That lack of corporate sponsorship of meaningful change leaves open only the approach of change by committee invention out of thin air. Nobody prefers this. But what else can be done? The fact WG14 and POSIX are warm to doing committee invention in the area of i/o shows just how much frustration with the status quo has built up. Niall