> Date: Wed, 10 May 2023 18:02:53 +0200 > From: Jakub Jelinek <ja...@redhat.com> > Cc: gabrav...@gmail.com, jwakely....@gmail.com, fwei...@redhat.com, > gcc@gcc.gnu.org, ar...@aarsen.me > > > If some program is plainly invalid, not just because the criteria of > > validity have shifted, then yes, such a program should be rejected. > > Many of the accepts-invalid cases are when something used to be valid in some > older standard and is not valid in a newer standard, often even changes > meaning completely in even newer standard. > Examples include e.g. the auto keyword, which means something completely > different in C++11 and later than what it meant in C++98, or say comma in > array reference in C++17 vs. C++20 vs. C++23 (a[1, 2] is the same as a[(1, 2)] > in C++17, got deprecated in C++20 and is ill-formed or changed meaning > in C++23 (multi-dimensional array operator). > Or any time something that wasn't a keyword in older standard version > and is a keyword in a newer standard. > alignas/alignof/nullptr/static_assert/thread_local in C++11 and C23, > char16_t/char32_t/constexpr/decltype/noexcept in C++11, > constinit/consteval in C++20, > bool/false/true/typeof_unqual in C23. > > int bool = 1; > is completely valid C17 if one doesn't include <stdbool.h> header, > or > int static_assert = 2; > valid C17 if one doesn't include <assert.h> > etc. These used to compile and will no any longer wheen using -std=c2x or > in a few years when -std=gnu23 becomes the default will not compile by > default, even when it used to be valid C17.
The examples you gave are the ones I could accept as "good reasons" for breaking backward compatibility. That's because breaking that is unavoidable if GCC wants to support the newer standard. That is not the case we are discussing, AFAIU. Or at least no one has yet explained why accepting those old K&R programs will adversely affect the ability of GCC to compile C2x programs.
