<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 13 March 2014 14:37, Sarath Kodali <span dir="ltr"><<a href="mailto:sarath@dummy.com" target="_blank">sarath@dummy.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On Thursday, 13 March 2014 at 01:18:14 UTC, Chris Williams wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Thursday, 13 March 2014 at 00:48:15 UTC, Walter Bright wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 3/12/2014 5:18 PM, Andrei Alexandrescu wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
We are opposed to having compiler flags define language semantics.<br>
</blockquote>
<br>
Yeah, that's one of those things that always seems like a reasonable idea, but experience with it isn't happy.<br>
</blockquote>
<br>
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.<br>
<br>
I think the answer to #1 is to not introduce such changes lightly nor frequently.<br>
<br>
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.<br>

</blockquote>
<br></div></div>
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.<br>
</blockquote><div><br></div><div>That's not the way business works, at least, not in my neck of the woods.</div><div>Having been responsible for rolling out many compiler/toolset/library upgrades personally, that's simply not how it's done.</div>
<div><br></div><div>It is assumed that infrastructural update may cause disruption. No sane business just goes and rolls out updates without an initial testing and adaptation period.</div><div>Time is allocated to the upgrade process, and necessary changes to workflow are made by an expert that performs the upgrade.</div>
<div>In the case of controlled language feature deprecation (as opposed to the std.json example), it should ideally be safe to assume an alternative recommendation is in place, and it was designed to minimise disruption.</div>
<div>In the case we are discussing here, the disruption is small and easily addressed.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
</blockquote><div><br></div><div>In my experience, C/C++ is wildly unstable.</div><div>I've been responsible for managing C compiler updates on many occasions, and they often cause complete catastrophe, with no warning or deprecation path given!</div>
<div>Microsoft are notorious for this. Basically every version of MSC is incompatible with the version prior in some annoying way.</div><div><br></div><div>I personally feel D has a major advantage here since all 3 compilers share the same front-end, and has a proper 'deprecated' concept (only recently introduced to C), and better compile time detection and warning opportunities.</div>
<div>Frankly, I think all this complaining about breaking changes in D is massively overrated. C is much, much worse!</div><div>The only difference is that D releases are more frequent than C releases. That will change as the language matures.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.</blockquote><div><br></div><div>
This is possibly true. It's a tricky balancing act.</div><div><br></div><div>I'd rather see D take a more strict approach here, so that we don't end up in the position where 30-year-old D code still exists alongside 'modern' D code written completely differently, requiring to be compiled with a bunch of different options.</div>
<div>The old codebases should be nudged to update along the way. I would consider it a big mistake to retain the ancient-C backwards compatibility.</div></div></div></div>