llvm dev - Mar 2015 - [LLVMdev] https://llvm.org/bugs/show_bug.cgi?id=22771 and N2255: as good as it gets?

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2255.html has the
following note about std::is_convertible :
> Library implementor's note: Except for the protected/private access
checks, and the ambiguity checks, this specification is completely implementable
in C++03 (even without rvalue references). However it is intended that this be
implemented with compiler help to get the access and ambiguity checks correct.
This note would seem to apply to examples like Richard Smith's tiny test
case listed in https://llvm.org/bugs/show_bug.cgi?id=22771 relative to libc++:
> Here's a testcase that fails with Clang:
> 
> #define __has_feature(x) 0
> #include <type_traits>
> class X { X(const X&); };
> bool b = std::is_convertible<const X&, X>::value;
> 
> (Using a public deleted copy constructor fails similarly.)
It sounds like there are going to be limitations to any library-only solution
(i.e.,  to any fallback implementation of std::is_convertible).

So for a failing fallback test example to matter likely requires that the
failure not  depend on accessibility checks or ambiguity checks --or at least to
depend on them in only certain specific ways.

[This likely explains Dimitry Andric's report (comment 4) of the failure for
the above example.]

Might it be that the improvement that is being tested (
https://llvm.org/bugs/attachment.cgi?id=14073 ) is sufficient given the general
limitations on library-only code solutions?

Going the other way: if one wants code (such as llvm/clang source) to survive
environments that need to use a library-only fallback then that code likely
needs to avoid depending on accessibility or ambiguity properties for its direct
or indirect use of std::is_convertible. I do not know what criteria llvm/clang
uses for such issues.

==Mark Millard
markmi at dsl-only.net