Steve, yes, this inconsistency was deliberate; see N2418
<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2418.pdf> (the paper
that proposed u8 character literals for C2X). The choice was made
anticipating a char8_t type as then proposed by N2231
<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2231.htm>. As Robert
already noted, the adoption of N2653
<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2653.htm> at the last
WG14 meeting resolves the inconsistency.

Tom.

On 2/28/22 3:39 PM, Robert Seacord via Liaison wrote:
> If I remember correctly, we voted this paper
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2653.htm into C23 at
> the last meeting so you probably want to refer to this as it changes
> things.
>
> Thanks,
> rCs
>
> On Mon, Feb 28, 2022 at 3:29 PM Steve Downey via Liaison
> <liaison_at_[hidden]> wrote:
>
> Looking at N 2731
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2731.pdf to see
> how conversion from source encoding to u8 literal is handled, I
> notice that 6.4.5 String Literals para 6 says "For UTF–8 string
> literals, the array elements have type char", although in 6.4.4.4
> Character Constants para 12 it says "A UTF–8 character constant
> has type unsigned char."
>
> Is the inconsistency a bug or deliberate?
> _______________________________________________
> Liaison mailing list
> Liaison_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/liaison
> Link to this post: http://lists.isocpp.org/liaison/2022/02/1009.php
>
>
> _______________________________________________
> Liaison mailing list
> Liaison_at_[hidden]
> Subscription:https://lists.isocpp.org/mailman/listinfo.cgi/liaison
> Link to this post:http://lists.isocpp.org/liaison/2022/02/1010.php