Final by default?

[Jerry]

"Daniel Murphy" <yebbliesnospam at gmail.com> writes:

> "Don"  wrote in message news:ekymfpqyxasvelcixrjp at forum.dlang.org...
>
>> I agree completely.
>>
>> Some things that really should be fixed, don't get fixed because of a
>> paranoid fear of breaking code. And this tends to happen with the issues
>> that can give nice warning messages and are easy to fix...
>>
>> Yet there are still enough bugs that your code breaks every release anyway.
>> We need to lose the fantasy that there is legacy code which still compiles.
>> Anything more than a year or so old is broken already.
>
> As usual I agree with every single thing in this post, and Sean's. Regressions
> are bad but have nothing to do with using slow, controlled deprecation to make
> the language better. 

I add my +1 to this side of the argument.  Performance matters.  D is of
interest to me as a language that is clean but performs well out of the
box.  The harder it is to make it perform well, the more we might as
well continue to use C++.  I've fixed multiple preformance problems
involving virtual functions being used where they don't belong.  I want
to see final by default for performance.

I also want to see final by default as I work in an area where many APIs
are created by people who are trying things out, rather than designing
software for the long term.  Invariably, some of these APIs will linger
and be very hard to fix down the road.  I'd *much* rather these
maintenance headaches not be virtual.

I also second the point that a controlled deprecation cycle is vastly
different from accidental breakage.  It can be planned for as long as
the communication happens.  It might be very useful to have a roadmap
page that lists every deprecation cycle that is planned or ongoing.

Jerry