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

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.

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.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca