> It'd take an ABI break to implement, but wouldn't using inline namespaces under std mean backward compatiblity is possible in the future? Indeed. It seems t

> It'd take an ABI break to implement, but wouldn't using inline namespaces under std mean backward compatiblity is possible in the future? Indeed. It seems that the author of the article is very opinionated about what he feels should be changed in the standard, but tries to pass off catastrophic descriptions of what will be the consequences of not having his way with the c++ standardization effort. Objectively, the author defended a bunch of backward-incompatible changes that would force a break in the ABI and create major problems to C++ users just to accommodate minor changes to the standard. Sounds like the C++ standardization committee clearly made the right call, and at worse nothing of value was changed. Yet, the problem here is not the ABI but how minor changes were being pushed in a way that caused major breakages. For example, why is the author pushing profound changes to std::regex, such as changing the underlying data type, and still insisting in not presenting them as a new, separate component? In fact, it would not be the first time this path was taken, as even the author states that scoped_lock was added as a separate component to avoid the mistake of proposing changes to old components that would create ABI breaks. Frankly, the author sounds a bit petty and with an axe to grind, and lacking in honesty with regards to his complains, as is demonstrated by his choice in stating thestandard library has died just because his pet proposals, all minor and inconsequential but that would lead to major breakages and an extensive list of backward compatibility problems, were not accepted.