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

On 1/24/25 21:40, Kaz Kylheku wrote:

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

...

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.

True. Making it the responsibility of C was a decision made by the C
committee, not something they had to do. That decision makes a key part
of C's identity. If you don't like that decision, I strongly recommend
choosing a language managed by an organization that attaches less
importance to backwards compatibility.

...

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

They don't. They "pretend" to be people who place a high, but not
absolute, priority on maintaining backwards compatibility. In fact, they
"pretend" it so well that it's actually the reality.

...

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.

It's not what it means at all. Backwards compatibility is a relationship
between two different versions of the standard. If one of those two
versions is not, in any way, involved, the concept is meaningless. When
you use a modern compiler that has a mode where it can compile C2023
code, but use it in a different mode where it supports C90, it isn't a
C2023 compiler that's backwards compatible with C90. In that mode, it is
simply a C90 compiler.