The following is almost, but not completely, entirely unlike a topical post;
I think it's still related to C specifically enough to be interesting here,
but you have been warned.
jacob said:
In my opinion, a compiler that introduces an extension should be
fair to the users that use that extension and never take it back
without a means to the users to keep their code as is.
Fairness is in the eye of the beholder. In my opinion, compiler writers have
a duty to clearly inform their users of features that aren't standard and
what their policies on maintaining such features are, so that users can make
an informed decision -- but that's all.
There are good reasons why designers choose not to make backwards
compatibility absolute, one of the most prominent being maintainability. It
is deceptively easy to ruin your chances of remaining successful by turning
your program (or indeed your language) into a pile of privileged historical
accidents. Pundits might argue C itself suffers at least partially from
exactly this problem.
Absolute backwards compatibility is unreasonable. Even Microsoft, one of the
the most backwards companies... I mean, one of the most backwards-compatible
companies in the world[*], hasn't always been able to ensure that every
program that ran on one version of their operating systems ran on the next
-- sometimes things just have to give.
And Microsoft is catering to people who are unable to change their programs
themselves and mostly unwilling to have them changed: the end users. If end
users cannot be fully insulated from changes, how is it reasonable to expect
developers to be?
It is apparently not the way gcc works, maybe as a result of the
C++ habit of invalidating code bases.
This is a direct result of the C++ standard needing several years to
stabilize. Compiler writers are hardly to blame, unless you propose they
should have written compilers capable of emulating every previous version of
themselves (which is certainly possible, but after a moment's thought also a
good illustration of why this is problematic at best and meaningless at worst).
In C++ is a daily problem that code that works with version x.x of the
compiler will stop working in version x.x+1. Now the compiler is more
compliant with the standards, the compiler people will argue. It rejects
previously working code.
Again: blame C++ for this, not the C++ compilers. If your language isn't
stable, how can you expect your code to be? On the other hand: if your
language *is* stable, how reasonable is it to expect that the code you write
outside the stable base maintains its semantics?
This has been exported to C also. Extensions that worked are now
discontinued.
Oh, it's not just extensions. Aren't you just appalled that you can't
compile some K&R C code with the latest versions of gcc? As if rewriting a
fully functioning program to conform to ANSI improves it! How much would it
have cost to keep full K&R support in the compiler, anyhow?
The regrettable result of changing the language is that developers are kept
busy for no immediate reward. The less tangible rewards are a compiler
that's easier to maintain and an actual incentive to move to conforming
code, which is easier to maintain in the long run.
Those people who'd argue that they don't care enough about a maintainable
compiler or conforming code are free to keep using the existing version or
branch of their compiler for as long as it will serve them. TANSTAAFL.
S.
[*]I know MS bashing is considered unrefined these days, but this was too
good to pass up.