I didn't follow, but AFAIK char8_t is said to be distinct, not an alias,
it was never suggested to make uint8_t a distinct type from unsigned char.

Peter

Aaron Peter Bachmann via Liaison wrote on 07.06.21 09:45:
>
>
> Hello!
> At least for C if uint8_t is not an alias for char, signed char and
> unsigned char is very undesirable.
> [u]intxy_t are just typedefs.
> Having a special case uint8_t makes C less regular and breaks existing
> code.
> For performance we have restrict.
>
> Regards, Aaron Peter Bachmann
>
> On 6/6/21 5:49 PM, Tom Honermann wrote:
>> On 6/5/21 4:27 PM, Victor Yodaiken wrote:
>>>
>>>
>>> On Sat, Jun 5, 2021 at 9:51 AM Tom Honermann <tom_at_[hidden]
>>> <mailto:tom_at_[hidden]>> wrote
>>>
>>>>
>>>> Why is it not desirable?
>>>
>>> I mentioned that there is a tradeoff between code efficiency and
>>> safety in the updates made to the paper.
>>>
>>> maybe im looking at the wrong version but i dont see any discussion
>>> of that
>>
>> From here
>> <https://rawgit.com/sg16-unicode/sg16/master/papers/n2653.html#do_char8_t_type>.
>> Start reading at the paragraph that begins with "Additional motivation
>> for distinct integer types is the ability to specify them as
>> non-aliasing types".
>>
>> > The following example code would be well-formed in C regardless of
>> whether char8_t is specified as a new integer type or as a typedef
>> name of an existing character type. If char8_t is specified as a
>> typedef name of an existing character type, then the example also
>> works as expected because it does not violate aliasing rules. However,
>> if char8_t is specified as a new integer type, then the example would
>> exhibit undefined behavior because an object of type char is accessed
>> using the char8_t type (assuming no new special provisions added to
>> C17 6.5, Expressions, paragraph 7). *Thus, there is a trade-off
>> between code efficiency and safety inherent in how **char8_t**is
>> defined*.
>>
>>>>
>>>> Thank you, good suggestion.
>>>>
>>>> I updated the "typedef name vs a new integer type"
>>>> <https://rawgit.com/sg16-unicode/sg16/master/papers/n2653.html#do_char8_t_type>
>>>>
>>>> section and have now submitted the paper to
>>>>
>>>>
>>>> That seems more useful. What is the purpose of creating more
>>>> type restrictions?
>>>
>>> The usual reasons; a coherent object model enables type based
>>> analysis for improved code generation and other forms of static
>>> analysis.
>>>
>>>
>>> What makes it coherent to have unnecessary type ub?
>>> What evidence shows tbaa improves performance on real programs?
>>> My concern is that there is too much ub in the standard already
>>
>> I'm not going to debate this here as other forums are better suited
>> for discussing the pros and cons of the C object model. I'm confident
>> WG14 is well positioned to make a decision with regard to this paper.
>>
>> Tom.
>>
>
> _______________________________________________
> Liaison mailing list
> Liaison_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/liaison
> Link to this post: http://lists.isocpp.org/liaison/2021/06/0606.php

-- 
Peter Sommerlad
Better Software: Consulting, Training, Reviews
Modern, Safe & Agile C++
peter.cpp_at_[hidden]
+41 79 432 23 32