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

[Mark Millard]

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