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

Reply via email to