[Bug libstdc++/89102] New: 'common_type' of single abominable function should not have a nested typename
alisdairm at me dot com
gcc-bugzilla@gcc.gnu.org
Tue Jan 29 13:42:00 GMT 2019
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89102
Bug ID: 89102
Summary: 'common_type' of single abominable function should not
have a nested typename
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: alisdairm at me dot com
Target Milestone: ---
According to the formula for 'common_type', as an abominable function type does
not have a valid return type for 'declval', the trait should not have a nested
'type' name.
The following program shows this is not the case (I have not tried to work out
what the nested name aliases, probably the type itself):
template <typename TestType, typename = void>
inline constexpr bool DetectType = false;
template <typename TestType >
inline constexpr
bool DetectType<TestType, std::void_t<typename TestType::type>> = true;
// Quick proof detector works correctly
struct NoType {};
struct HasType { using type = HasType; };
static_assert( DetectType<HasType> );
static_assert(!DetectType<NoType> );
auto main() -> int {
static_assert(!DetectType< std::common_type<int( ) & > >);
static_assert(!DetectType< std::common_type<int(...) & > >);
static_assert(!DetectType< std::common_type<int( ) & noexcept> >);
static_assert(!DetectType< std::common_type<int(...) & noexcept> >);
return 0;
}
I have also tested with gcc9 in development, but MacPorts stopped updating
around October 2018, so my test environment is quite out of date - so only
claiming the bug
against the latest release version I have tested.
More information about the Gcc-bugs
mailing list