https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87093
Bug ID: 87093
Summary: is_constructible (__is_constructible() instrinsic)
explicitly instantiates conversion member function of
source
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: TonyELewis at hotmail dot com
Target Milestone: ---
This following fails to compile under `g++ -fsyntax-only -std=c++17` but
succeeds under `clang++ -fsyntax-only -std=c++17` :
~~~
#include <type_traits>
template <typename T> struct x {
operator bool() {
static_assert( ! ::std::is_same_v<T, T> );
return false;
}
};
inline constexpr auto a = ::std::is_constructible<bool, x<int>>{};
~~~
The error is:
~~~
a.cpp: In instantiation of ‘x<T>::operator bool() [with T = int]’:
/usr/include/c++/8/type_traits:932:12: required from ‘struct
std::is_constructible<bool, x<int> >’
a.cpp:10:65: required from here
a.cpp:5:18: error: static assertion failed
static_assert( ! ::std::is_same_v<T, T> );
^~~~
~~~
I think this means that GCC's `__is_constructible()` intrinsic is explicitly
instantiating x's `operator bool()` when trying to figure out whether a bool
can be constructed from an x, whereas Clang' `__is_constructible()` isn't.
>From a quick look, I can't see anything obvious in the standard about whether
either GCC or Clang is wrong here and I guess it's arguable either way. But I
think I'd lean towards arguing that Clang's behaviour better reflects what I'd
expect from traits.
I've replicated this on Godbolt's GCC 9.0.0 20180823.
