<p dir="ltr">On Jan 23, 2016 10:09 PM, "Howard Hinnant" <<a href="mailto:howard.hinnant@gmail.com">howard.hinnant@gmail.com</a>> wrote:<br>
><br>
> On Jan 23, 2016, at 3:59 PM, Richard Smith <<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>> wrote:<br>
> ><br>
> >> 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.<br>
> >><br>
> > Thanks, Howard, it's useful to know how we got here.<br>
> ><br>
> > 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.<br>
> ><br>
><br>
> This thread started with evidence from the field to the contrary.</p>
<p dir="ltr">We have evidence from the field that the lack of overloads of ::fabs causes (usually hard to detect precision loss) bugs. This thread concerns a nonstandard extension that I would imagine is only used by a small minority of libc++ users, and we can handle it by supporting that extension directly in libc++. (Doing so would fix a couple of other issues: wrong return type, no support for __fp16 in std::fabs.)</p>