Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c
Subject: Re: "A diagram of C23 basic types"
Date: Thu, 3 Apr 2025 10:59:33 +0200
Organization: A noiseless patient Spider
Lines: 78
Message-ID: <vslilm$8mfb$1@dont-email.me>
References: <87y0wjaysg.fsf@gmail.com> <vsj1m8$1f8h2$1@dont-email.me>
 <vsj2l9$1j0as$1@dont-email.me> <vsjef3$1u4nk$1@dont-email.me>
 <vsjg6t$20pdb$1@dont-email.me> <vsjjd1$23ukt$1@dont-email.me>
 <vsjkvb$25mtg$1@dont-email.me> <vsjlkq$230a5$2@dont-email.me>
 <20250402232443.00003a7d@yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 03 Apr 2025 10:59:34 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="d65639e364606db0746acbec737df138";
	logging-data="285163"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19a8a97GAyWLAejzS91kQxyRDHKajngSCE="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:zf9f2b3xDZX9DjUATXsWEbVsBgw=
Content-Language: en-GB
In-Reply-To: <20250402232443.00003a7d@yahoo.com>
Bytes: 3934

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).