Re: "A diagram of C23 basic types"

On 02/04/2025 22:24, Michael S wrote:

On Wed, 2 Apr 2025 16:38:03 +0100
bart <bc@freeuk.com> wrote:
 

On 02/04/2025 16:26, Muttley@DastardlyHQ.org wrote:

On Wed, 2 Apr 2025 16:59:45 +0200
David Brown <david.brown@hesbynett.no> wibbled:

On 02/04/2025 16:05, Muttley@DastardlyHQ.org wrote:

I suspect the people who are happy with C never have any
correspondence with anyone from the committee so they get an
entirely biased sample. Just like its usually only people who had
a bad experience that fill in "How did we do"

 

surveys.

>
And I suspect that you haven't a clue who the C standards
committee talk to - and who those people in turn have asked.

>
By imference you do - so who are they?
  

11. nullptr for clarity and safety.

>
Never understood that in C++ never mind C. NULL has worked fine for
50 years.

>
And it's been a hack for 50 years. Especially when it is just:
>
    #define NULL 0
>
You also need to include some header (which one?) in order to use it.
I'd hope you wouldn't need to do that for nullptr, but backwards
compatibility may require it (because of any forward-thinking
individuals who have already defined their own 'nullptr').
>
>

 C23 is rather bold in that regard, adding non-underscored keywords as
if there was no yesterday. IMHO, for no good reasons.
 

It is bold, perhaps, but there are certainly good reasons.  As far as I can see we have some keywords that have dropped their underscore-capital form:
alignas
alignof
bool
static_assert
thread_local
And we have some new ones :
constexpr
false
nullptr
true
typeof
typeof_unequal
(Other new keywords, such as _Decimal32, have the underscore-capital form.)
While it is a good idea to avoid new non-reserved identifier keywords for compatibility, it would also be getting a bit silly to add <stdconstexpr.h>, <stdnullptr.h>, etc., to the existing <stdalign.h>, <stdbool.h>, etc.  It is an inconvenience for programmers to have to pull in a dozen extra headers just to be able to use new standard language features in a nice manner.
This does mean that some pre-C23 code will be incompatible with C23.  It is like C99 in that regard - it is a significantly bigger change than C17 was.  But in my opinion, it is good to see that C23 places a bit more relevance on newer code going forward, even though it is at the cost of some older code (particularly code written to pre-C99 standards).