Path: ...!weretis.net!feeder9.news.weretis.net!news.quux.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.lang.c
Subject: Re: Results of survey re. a new array size operator
Date: Wed, 29 Jan 2025 02:13:17 -0800
Organization: A noiseless patient Spider
Lines: 80
Message-ID: <861pwm2aiq.fsf@linuxsc.com>
References: <87a5bgsnql.fsf@gmail.com> <vn066i$28bkd$2@dont-email.me> <20250124121027.691@kylheku.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Date: Wed, 29 Jan 2025 11:13:18 +0100 (CET)
Injection-Info: dont-email.me; posting-host="ba8d9ca2da4b9314498ee7469992f70e";
	logging-data="2450859"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19iXzHoGgbLqVQ9ttmKs3+xEwhEb7RZSV0="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:8C7bZaTRKwNuFlYcf0Le91+T530=
	sha1:905ch5K8aZ2ZaiHs6KHjM5ssnd0=
Bytes: 4419

Kaz Kylheku <643-408-1753@kylheku.com> writes:

> On 2025-01-24, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>
>> 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.
>
> Backward compatibility matters in software.
>
> People use C compiler applications to open text documents of type
> C.
>
> All that matter is that there is a way to use their old document
> with the new application.
>
> It is almost purely a software matter, not requiring anything in
> the specification.
>
> The C++ people have already figured out this out, and are running
> with it (like crazy).
>
> It doesn't matter if the current language has a keyword "arraysize"
> which breaks every program that uses it as the name of something
> (goto label, struct member, variable, function ...) if
> the language implementation has an option like -std=c11
> under which that is not a keyword.
>
>> A lower case keyword would break any program that was
>
> That's like saying that the existence of Office 356 breaks every
> Word 97 document.
>
> That's only if Office 365 loses the ability to work with such a
> document;  the mere existence of the new format /per se/
> perpetrates no such harm.
>
> The problem with what I'm saying here is that it requires trust.
>
> The people specifying the language have to abandon their grasp of
> the reins of control on the compatibility issue and trust that the
> implementors will handle it in good ways for the benefit of their
> users.

It's hard to imagine a stance more antithetical to the point of
having a C standard in the first place.

> The people specifying the language also have to accept that
> the backward compatibility mechanism is not only out of their
> control, but that it has implementation-specific manifestations:
> the means by which an implementation is instructed to obey an
> older dialect isn't specified in the standard because they have
> decided that the manner of presenting a program for processing
> by an implementation is out of the Scope.
>
> Even if it were something that were somehow brought within the
> Scope, the standard couldn't go as far as to give a requirement
> like "a conforming impelmentation shall provide configurations
> for accepting programs in the following historic dialects of C:
> [...]"  You just can't do that.

These comments serve to underscore just how bad a decision it is
to add this unnecessary feature to the C standard.