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

On 2025-01-25, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:

On 1/24/25 15:24, Kaz Kylheku wrote:

On 2025-01-24, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:

...

One of the most important goals of the C standard is backwards
compatibility.

 
Backward compatibility matters in software.

>
C code is software, and so are C implementations, so I'm not sure what
that has to do with anything.
>
The committee has explicitly stated a
priority between those two kinds of software: "existing user code
matters; existing implementations don't".

Ensuring existing user code keeps working doesn't have to be a
responsibility of ISO C.

Catering to that at the standard level might not be optimal,
because it causes the committe to excessively fret about
backward compatibility at the specification level.

Whereas implemetations can pretty easily support backward compatibility
across incompatible dialects.

ISO C has not remained perfectly backward comaptible, so why
pretend to be the keepers of backward compatibility?

- // comments can be used to write a C90 program that isn't valid C99.

- The old auto keyword now has a new meaning. Ancient programs
  that used auto for automatic variables no longer work.

- The parameter list () meaning the same thing as (void)
  can break programs.

It is the practice of implementations providing dialect options that
helps things go smoothly. They give developers more choice in regard to
the timeline for upgrading their code to newer dialects.

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.

>
Backwards compatibility doesn't mean that you can still build your
program using an older version of the language.

That's not all it means, sure.

But If the compiler allows that, then it is definitely providing a
feature that can be called none other than backward compatibility.

It's just a feature of that program, not of the language; the language
isn't backward compatible. Just the translator speaks multiple
languages.

I get the point that if the changes at the language level are so rampant
that users have to keep using compilers in backward compatibility modes
for extended periods of time due to facing too much effort (and repeated
effort) at making their programs work with newer versions of the
language, that is a poor situation.

It means that you can
compile your code your code without change using the newest version of
the language. You only have to make changes to make use of new features
of the language, and you should be confident that you can do so without
worrying about some of the other new features breaking your existing code.

What matters is how much it breaks. Renaming an identifier in ten
places, versus thousands of nontrivial changes.

People have ported C code to C++, resolving conflicts on the use
of identifiers like new, class, private, ... and life went on.

I suspect that the ISO C people are so hell bent on backward
compatibility because they want everyone as much as possible to to use
the shiniest, newest standard; they don't want an ecosystem in which
people just tell their implementations to use an older dialect and
ignore the new thing.

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