From: thiago.adams@gmail.com   
      
   On 10/21/2025 3:51 PM, Keith Thompson wrote:   
   > Thiago Adams  writes:   
   >> On 10/21/2025 2:26 PM, Keith Thompson wrote:   
   >>> Thiago Adams  writes:   
   >>>> On 10/20/2025 7:19 PM, Keith Thompson wrote:   
   >>> [...]   
   >>>>> That raises another issue.   
   >>>>> The  header was introduced in C99.  In C99, C11, and C17,   
   >>>>> that header defines char16_t and char32_t.  C23 introduces char8_t.   
   >>>>   
   >>>> I think for all these typedefs related with language concepts, like   
   >>>> size_t which is related with sizeof, char8_t which is related with   
   >>>> u8"" char16_t u"", char32_t  U""... etc.. should be built-in typedefs.   
   >>>>   
   >>>> And even others that does not have a association with language   
   >>>> features like int16_t.   
   >>> By "built-in typedefs", do you mean typedefs that are visible   
   >>> without   
   >>> a #include?   
   >>>   
   >>   
   >> yes.   
   >>   
   >>> That would be unprecedented, but I suppose it could work.  But I'm not   
   >>> sure it would be all that advantageous.  The type of the result of   
   >>> sizeof is some implementation-defined unsigned integer type.  The   
   >>>  header merely provides a consistent name for that type.   
   >>> I can see that having language features depend (indirectly) on types   
   >>> defined in library headers is a bit messy, but I don't think it causes   
   >>> any real problems.   
   >>>   
   >>   
   >>   
   >> It's not really a problem, but it depends on the includes, which in   
   >> turn depend on the preprocessor.   
   >>   
   >> It seems like the language is partially configured through macros and   
   >> typedefs in includes.   
   >   
   > The way I'd describe it is that the type of a sizeof expression is   
   > chosen by the compiler, and the definition of size_t in    
   > documents that choice and makes it visible to programmers.   
   >   
   >> Some types that have direct relation with the language:   
   >>   
   >>      typedef typeof_unqual(sizeof(0)) size_t;   
   >>      typedef typeof_unqual(((char*)1)-((char*)0)) ptrdiff_t;   
   >>      typedef typeof_unqual(u8' ') char8_t;   
   >>      typedef typeof_unqual(u' ') char16_t;   
   >>      typedef typeof_unqual(U' ') char32_t;   
   >>      typedef typeof_unqual(L' ') wchar_t;   
   >>      typedef typeof_unqual(nullptr) nullptr_t;   
   >>   
   >> I think it does not make sense to have to include a file to describe   
   >> size_t because we can use sizeof without having to include anything.   
   >   
   > I suppose if I were defining a new language from scratch, I probably   
   > wouldn't have those types defined in library headers.  I might have   
   > made size_t a keyword, for example.   
   >   
   > One data point: C++ has wchar_t as a keyword, while C defines it as   
   > a typedef in .  C++'s wchar_t has the same representation   
   > as one of the other integral types, called its underlying type.   
   > That could have been a nice approach for C, but I'd say it's too   
   > late to fix it, and the benefits aren't worth the cost.   
   >   
      
   yes I think keywords make sense.  In some ways, all C types are   
   typedefs for the "real" types.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)