On Thursday, 13 March 2014 at 01:18:14 UTC, Chris Williams wrote:
On Thursday, 13 March 2014 at 00:48:15 UTC, Walter Bright wrote:
On 3/12/2014 5:18 PM, Andrei Alexandrescu wrote:
We are opposed to having compiler flags define language
semantics.
Yeah, that's one of those things that always seems like a
reasonable idea, but experience with it isn't happy.
I would imagine that the reasons for this goal are 1) to keep
the compiler and language sane, and 2) insufficient personel to
maintain legacy variants.
I think the answer to #1 is to not introduce such changes
lightly nor frequently.
For #2, since the codebase is now open sourced and, I presume,
your "clients" pay you to perform specific tasks, legacy
compilation features will end up being maintained either by
random people who fix it themselves, or a client who based his
code on an older version pays you to go into the legacy
branch/build target code. This is the way most open sourced
software works. Linux, GCC, emacs, etc. are all constantly
moving targets that only through people paying Red Hat and
others like them to make the insanity go away are able to work
together as a single whole.
If I'm a enterprise customer I would be very angry if my code
breaks with each new release of compiler. I will be angry
irrespective of whether I'm paying for the compiler or not.
Because every time my code breaks, I will have to allocate
resources to figure out the reason why a working production code
is broken and then have to test new code and testing can take
months to complete.
Languages are adopted by enterprises only when there is long term
stability to it. C code written 30 years back in K&R style still
compiles without any problem. Please enhance the language but
don't break existing code.
Also if something has to be deprecated, it should exist in that
deprecated state for at least for 5 years. Currently it is one
year and for enterprise customers that is a very short period.
- Sarath
