Steve, yes, this inconsistency was deliberate; see N2418 (the paper that proposed u8 character literals for C2X). The choice was made anticipating a char8_t type as then proposed by N2231. As Robert already noted, the adoption of N2653 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@lists.isocpp.org> 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@lists.isocpp.org
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@lists.isocpp.org
Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/liaison
Link to this post: http://lists.isocpp.org/liaison/2022/02/1010.php