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
[email protected]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
