Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: James Kuyper <jameskuyper@alumni.caltech.edu>
Newsgroups: comp.lang.c
Subject: Re: Results of survey re. a new array size operator
Date: Fri, 24 Jan 2025 08:56:34 -0500
Organization: A noiseless patient Spider
Lines: 23
Message-ID: <vn066i$28bkd$2@dont-email.me>
References: <87a5bgsnql.fsf@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 24 Jan 2025 14:56:35 +0100 (CET)
Injection-Info: dont-email.me; posting-host="3b73afc4db4b2cef9846b763bdfb0026";
	logging-data="2371213"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18lbzemAVmZuLRTekg0RmobtFI4PxlN570="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:nR3Y5qZh/+0AZsIbke88qqHVM80=
In-Reply-To: <87a5bgsnql.fsf@gmail.com>
Content-Language: en-US
Bytes: 2275

On 1/24/25 01:57, Alexis wrote:
> 
> Hi all,
> 
> JeanHeyd Meneide, a Project Editor for WG14, has just posted the results
> of a survey re. the preferred form of a new array size operator:
> 
> "There is a clear preference for a lowercase keyword, here, though it is
> not by the biggest margin. One would imagine that with the way we keep
> standardizing things since C89 (starting with _Keyword and then adding a
> header with a macro) that C folks would be overwhelmingly in favor of
> simply continuing that style. The graph here, however, tells a different
> story: while there’s a large contingency that clearly hates having
> _Keyword by itself, it’s not the _Keyword + stdkeyword.h macro that
> comes out on top! It’s just having a plain lowercase keyword, instead."

One of the most important goals of the C standard is backwards
compatibility. A lower case keyword would break any program that was
already using that keyword as a user-defined identifier. _Keyword avoids
that problem, because it's an identifier from the namespace reserved to
implementations. Therefore, any code already using that identifier for
some other purpose has undefined behavior anyway, so it's not a problem
as far as the C committee is concerned.