Final by default?

[Manu]

On 13 March 2014 14:37, Sarath Kodali <sarath at dummy.com> wrote:

> 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.
>

That's not the way business works, at least, not in my neck of the woods.
Having been responsible for rolling out many compiler/toolset/library
upgrades personally, that's simply not how it's done.

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.
Time is allocated to the upgrade process, and necessary changes to workflow
are made by an expert that performs the upgrade.
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.
In the case we are discussing here, the disruption is small and easily
addressed.

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.
>

In my experience, C/C++ is wildly unstable.
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!
Microsoft are notorious for this. Basically every version of MSC is
incompatible with the version prior in some annoying way.

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.
Frankly, I think all this complaining about breaking changes in D is
massively overrated. C is much, much worse!
The only difference is that D releases are more frequent than C releases.
That will change as the language matures.

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.


This is possibly true. It's a tricky balancing act.

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.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140313/ea299998/attachment.html>