Re: [PATCH 0/3]: C N2653 char8_t implementation

[Tom Honermann <tom@honermann.net>]

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.