Re: Results of survey re. a new array size operator

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.