Final by default?

[Joseph Rushton Wakeling]

On Thursday, 13 March 2014 at 04:58:05 UTC, Andrei Alexandrescu 
wrote:
> I hear you. Time to put this in a nice but firm manner: your 
> arguments were understood but did not convince.

The problem is that this remark could be made in both directions. 
  I understand some of the motivation for this decision, but the 
way it's been announced and rationalized is very problematic.

That naturally leads to questions about whether it's the right 
decision or not, and to be honest, I don't think the follow-ups 
from you and Walter have adequately addressed those concerns.

Problem 1 -- the announcement as made gives the impression that a 
known, planned, desirable breaking change with a well-defined 
deprecation path is to be cancelled because of a client's 
response to an unplanned and unannounced breakage.  You need to 
make the case for why well-signposted, well-executed deprecation 
paths are a problem that sits on the same level as the kind of 
unexpected breakage this client encountered.

Problem 2 -- perhaps there's a broader context that you can't 
discuss with us because of commercial confidentiality, but the 
impression given is that this decision has been taken 
substantially in reaction to one bad client response.  This gives 
the impression of a knee-jerk reaction made under stress rather 
than a balanced decision-making process.  More so because it's 
not clear if the client would have the same problem with a 
well-executed deprecation process.

Problem 3 -- I don't think this decision has adequately 
acknowledged the original rationale for favouring 
final-by-default.  Walter has discussed the speed concern, but 
that was not the killer argument -- the one which swung the day 
was the fact that final-by-default makes it easier to avoid 
making breaking changes in future -- see e.g.:
http://forum.dlang.org/thread/pzysdctqxjadoraeexaa@forum.dlang.org?page=10#post-mailman.246.1386164839.3242.digitalmars-d:40puremagic.com
http://www.artima.com/intv/nonvirtualP.html

So, if avoiding breaking change in future is a strong goal, 
allowing the transition to final-by-default is a clear 
contribution to that goal.

Finally, I'd say that to my mind, these kinds of 
announcements-by-fiat that come out of the blue and without 
warning, while not as bad as unexpected code breakage, are still 
pretty bad for the D user community.  We need to be able to have 
trust in the firm decisions and understandings reached here in 
community discussions, that either they will be adhered to or 
that there will be prior notice and discussion before any 
counter-decision is finalized.  This is as much part of stability 
and reliability as the code in the compiler and the libraries.

Best wishes,

     -- Joe