Final by default?

Iain Buclaw ibuclaw at gdcproject.org
Thu Mar 13 11:19:00 PDT 2014


On 12 Mar 2014 22:50, "Walter Bright" <newshound2 at digitalmars.com> wrote:
>
> The argument for final by default, as eloquently expressed by Manu, is a
good one. Even Andrei agrees with it (!).
>
> The trouble, however, was illuminated most recently by the std.json
regression that broke existing code. The breakage wasn't even intentional;
it was a mistake. The user fix was also simple, just a tweak here and there
to user code, and the compiler pointed out where each change needed to be
made.
>
> But we nearly lost a major client over it.
>

std.json isn't precisely on the list of modules that showcase Phobos in a
good light.  We'd be better off giving the module some TLC and update the
API so it's consistent with the rest of Phobos in regards to coding
standards and unittest coverage.

> We're past the point where we can break everyone's code. It's going to
cost us far, far more than we'll gain. (And you all know that if we could
do massive do-overs, I'd get rid of put's auto-decode.)
>
> Instead, one can write:
>
>    class C { final: ... }
>
> as a pattern, and everything in the class will be final. That leaves the
"but what if I want a single virtual function?" There needs to be a way to
locally turn off 'final'. Adding 'virtual' is one way to do that, but:
>
> 1. there are other attributes we might wish to turn off, like 'pure' and
'nothrow'.
>
> 2. it seems excessive to dedicate a keyword just for that.
>
> So, there's the solution that has been proposed before:
>
>    !final
>    !pure
>    !nothrow
>    etc.

Yuck.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140313/123abfbd/attachment-0001.html>


More information about the Digitalmars-d mailing list