Final by default?

[Andrei Alexandrescu]

On 3/13/14, 7:48 AM, Joseph Rushton Wakeling wrote:
> 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.

At a level it's clear it's not a matter of right or wrong but instead a 
judgment call, right? Successful languages go with either default.

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

The breakage was given as an example. We would have decided the same 
without that happening.

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

More than sure a well-executed deprecation process helps although it's 
not perfect. We're not encumbered by exhausting confidentiality 
requirements etc.

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

There's some underlying assumption here that if we "really" understood 
the arguments we'd be convinced. Speaking for myself, I can say I 
understand the arguments very well. I don't know how to acknowledge them 
better than I've already done.

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

Thanks for being candid about this. I have difficulty, however, 
picturing how to do a decision point better. At some point a decision 
will be made. It's a judgment call, that in some reasonable people's 
opinion, is wrong, and in some other reasonable people's opinion, is 
right. For such, we're well past arguments' time - no amount of arguing 
would convince. I don't see how to give better warning about essentially 
a Boolean decision point that precludes pursuing the converse design path.


Andrei