rsmith added a comment. Counterproposal: in `-std=*++14` onwards, treat this construct as a user-defined literal, but fall back on the built-in interpretation if name lookup doesn't find an `operator""i` function. (The two interpretations only conflict if the source code explicitly does something like `using namespace std::complex_literals;`, which seems like a pretty big clue that the user expected `1.0i`to be `std::complex<double>` rather than `_Complex double`.)
If we find that's not enough for GCC compatibility in practice (perhaps in old code using `using namespace std;`), we can consider whether we want to make `-std=gnu++*` cause the built-in interpretation of the `i*` suffixes to be preferred over the overloaded interpretations. ================ Comment at: clang/lib/Lex/LiteralSupport.cpp:656 // "i", "if", and "il" are user-defined suffixes in C++1y. - if (*s == 'i' && PP.getLangOpts().CPlusPlus14) + if (*s == 'i' && !PP.getLangOpts().GNUMode) break; ---------------- I'm unconvinced this is sufficient justification to remove this previously-supported extension from `-std=c*` and `-std=c++98` modes. https://reviews.llvm.org/D33424 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits