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/pzysdctqxjadoraee...@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
