Date: Tue, 29 Sep 2020 17:59:40 -0400
In general, lexing stability is not guaranteed for C++. For example, we
added <=>.
This means that the following program changes in behaviour between C++17
and C++20:
template <auto> int foo(...);
template <typename T>
auto bar(T &t) -> char (*)[0 ? sizeof(foo<&T::operator<=> != nullptr > (t))
: 42];
template <typename T>
void bar(const T &t);
struct A {
bool operator<=(const A &);
friend decltype(nullptr) operator>(decltype(nullptr), const A &);
} a;
int main(void) { bar(a); }
This was, however, a change made by the C++ committee and not by an
external group.
I am concerned if syntactically significant properties of characters may
change between versions of UCS.
The example that comes to mind is the possibility of a line separator
character being added to UCS that would change where a C++-style // comment
ends.
Perhaps this is motivation to ban source code with unassigned characters
outside of string and character literals.
Maybe I'm just late to the party?
-- HT
added <=>.
This means that the following program changes in behaviour between C++17
and C++20:
template <auto> int foo(...);
template <typename T>
auto bar(T &t) -> char (*)[0 ? sizeof(foo<&T::operator<=> != nullptr > (t))
: 42];
template <typename T>
void bar(const T &t);
struct A {
bool operator<=(const A &);
friend decltype(nullptr) operator>(decltype(nullptr), const A &);
} a;
int main(void) { bar(a); }
This was, however, a change made by the C++ committee and not by an
external group.
I am concerned if syntactically significant properties of characters may
change between versions of UCS.
The example that comes to mind is the possibility of a line separator
character being added to UCS that would change where a C++-style // comment
ends.
Perhaps this is motivation to ban source code with unassigned characters
outside of string and character literals.
Maybe I'm just late to the party?
-- HT
Received on 2020-09-29 16:59:59