<p dir="ltr">On Jan 23, 2016 9:47 PM, "Howard Hinnant via cfe-dev" <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br>
><br>
> It was *never* intended to add the C++ overloads to the global namespace.<br>
><br>
> I can now see how that is indeed what is written.  Believe me, it was the farthest thought from *anyone’s* mind when these words were voted in.  This is demonstrable by looking at the issue which introduced these words:<br>
><br>
> <a href="http://cplusplus.github.io/LWG/lwg-defects.html#456">http://cplusplus.github.io/LWG/lwg-defects.html#456</a><br>
><br>
> The description includes:<br>
><br>
> > The C headers are often beyond the direct control of C++ implementors. In some organizations, it's all they can do to get a few #ifdef __cplusplus tests added. Third-party library vendors can perhaps wrap the C headers. But neither of these approaches supports the drastic restructuring required by the C++ Standard. As a result, it is still widespread practice to ignore this conformance requirement, nearly seven years after the committee last debated this topic. Instead, what is often implemented is:<br>
> ><br>
> >       • Including the header <xxx.h> declares a C name in the global namespace.<br>
> >       • Including the header <cxxx> declares a C name in the global namespace (effectively by including <xxx.h>), then imports it into namespace std with an individual using declaration.<br>
><br>
> This was the issue:  C++ lib vendors *not having control* over the C headers.  The furthest thing from our mind was adding *more* stuff to the C headers!<br>
><br>
> Martin is 100% correct as far as historical intent goes.  The mis-interpretation of these words by Richard and Eric is evidence that the standard remains buggy in this area.</p>
<p dir="ltr">Thanks, Howard, it's useful to know how we got here.</p>
<p dir="ltr">For what it's worth, though, I think the words we have in the standard now do say the best thing for users, striking a balance between C compatibility and bug avoidance (even if they don't match the historical intent), and would argue against changing them -- especially as we do now have an implementation that follows them.</p>