On 6/7/21 5:03 PM, Joseph Myers wrote:
On Sun, 6 Jun 2021, Tom Honermann via Gcc-patches wrote:
These changes do not impact default gcc behavior. The existing -fchar8_t
option is extended to C compilation to enable the N2653 changes, and
-fno-char8_t is extended to explicitly disable them. N2653 has not yet been
accepted by WG14, so no changes are made to handling of the C2X language
dialect.
Why is that option needed? Normally I'd expect features to be enabled or
disabled based on the selected language version, rather than having
separate options to adjust the configuration for one very specific feature
in a language version. Adding extra language dialects not corresponding
to any standard version but to some peculiar mix of versions (such as C17
with a changed type for u8"", or C2X with a changed type for u8'') needs a
strong reason for those language dialects to be useful (for example, the
-fgnu89-inline option was justified by widespread use of GNU-style extern
inline in headers).
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).
The ability to opt-in or opt-out of the feature eases migration by
enabling source code compatibility. C and C++ standards are not
published at the same cadence. A project that targets C++20 and C17 may
therefore have a need to either opt-out of char8_t support on the C++
side (already possible via -fno-char8_t), or to opt-in to char8_t
support on the C side until such time as the targets change to C++20(+)
and C23(+); assuming WG14 approval at some point.
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.
It would be appropriate to document this as an experimental feature
pending WG14 approval. If WG14 declines it or approves it with
different behavior, the feature can then be removed or changed.
The option could also be introduced as -fexperimental-char8_t if that
eases concerns, though I do not favor that approach due to misalignment
with the existing option for C++.
Tom.
