On Fri, 11 Jun 2021, Tom Honermann via Gcc-patches wrote: > The option is needed because it impacts core language backward compatibility > (for both C and C++, the type of u8 string literals; for C++, the type of u8 > character literals and the new char8_t fundamental type).
Lots of new features in new standard versions can affect backward compatibility. We generally bundle all of those up into a single -std option rather than having an explosion of different language variants with different features enabled or disabled. I don't think this feature, for C, reaches the threshold that would justify having a separate option to control it, especially given that people can use -Wno-pointer-sign or pointer casts or their own local char8_t typedef as an intermediate step if they want code using u8"" strings to work for both old and new standard versions. I don't think u8"" strings are widely used in C library headers in a way where the choice of type matters. (Use of a feature in library headers is a key thing that can justify options such as -fgnu89-inline, because it means the choice of language version is no longer fully under control of a single project.) The only feature proposed for C2x that I think is likely to have significant compatibility implications in practice for a lot of code is making bool, true and false into keywords. I still don't think a separate option makes sense there. (If that feature is accepted for C2x, what would be useful is for people to do distribution rebuilds with -std=gnu2x as the default to find and fix code that breaks, in advance of the default actually changing in GCC. But the workaround for not-yet-fixed code would be -std=gnu11, not a separate option for that one feature.) > > I think the whole patch series would best wait until after the proposal > > has been considered by a WG14 meeting, in addition to not increasing the > > number of language dialects supported. > > As an opt-in feature, this is useful to gain implementation and deployment > experience for WG14. I think this feature is one of the cases where experience in C++ is sufficiently relevant for C (although there are certainly cases of other language features where the languages are sufficiently different that using C++ experience like that can be problematic). E.g. we didn't need -fdigit-separators for C before digit separators were added to C2x, and we don't need -fno-digit-separators now they are in C2x (the feature is just enabled or disabled based on the language version), although that's one of many features that do affect compatibility in corner cases. -- Joseph S. Myers jos...@codesourcery.com
