https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79228
Bug ID: 79228
Summary: __complex__ extension interferes with C++14 UDLs for
std::complex
Product: gcc
Version: 6.3.1
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
The following is valid C++14 but fails with the default -std=gnu++14
#include <complex>
int main()
{
using namespace std::complex_literals;
auto a = std::abs(0.0i);
}
This extension requires the standard library to overload every function taking
a std::complex<T> argument so it also works with __complex__ T, and requires
users to do the same if they want their code to be portable to GCC.
Only the 'i' suffix clashes, the float and long double forms are not ambiguous:
GNU | C++14
-------|------_
0.0fi | 0.0if
0.0i | 0.0i
0.0li | 0.0il
Clang simply disables the non-standard 'i' suffix for C++14 and above:
prog.cc:3:31: error: no matching literal operator for call to 'operator""i'
with argument of type 'long double' or 'const char *', and no matching literal
operator template
__complex__ double d = 0.0i;
^
1 error generated.
The alternative 'j' suffix still works with Clang.
Another option would be to look for a UDL first and only if
std::literals::complex_literals::operator""i is not found treat it as the GNU
extension. I would prefer to just disable it though, the 'j' form would still
be usable to get the GNU semantics.
