On Mon, Oct 22, 2018 at 8:27 PM Robert Ramey via Boost
On 10/22/18 10:13 AM, Mike Dev via Boost wrote:
Interesting point to think about: If you look at how standardization of communication protocols work (e.g. USB, Wifi PCI), they don't standardize established practice at all.
True, but their not standardizing any practice. They don't approve code or APIS etc. The leave that to someone else. They stick to the legitimate goals of standardization.
I believe that one of the original goals is to "standardize existing practice" and perhaps they shouldn't do that. One thing that they do which no one else can do is specify language syntax and semantics. Expanding too far beyond this essential function can compromise the successful accomplishment of that very function.
The problem is defining that "too far beyond this essential function". Is it unique_ptr? Ranges? 2D graphics? In my view, the following are good reasons/potential candidates: * Anything that is universally useful, i.e. repeated over and over in all projects with a similar implementation (e.g. containers, array, string, unique_ptr, regexp...), even if the standard one would not be perfect for all projects. * Anything that is "set in stone" or comes from other standards (e.g. math, chrono...). * Anything that requires or benefits from compiler support, i.e. anything that should be the responsibility of compiler writers, rather than third-party libraries which end up with a thousand #ifdefs (e.g. static_assert, contracts, stacktrace...) * ... Cheers, Miguel