Final by default?

[Walter Bright]

On 3/14/2014 5:06 AM, Manu wrote:
> In my experience, API layout is the sort of performance detail that library
> authors are much more likely to carefully consider and get right. It's higher
> level, easier to understand, and affects all architectures equally.
> It's also something that they teach in uni. People write books about that sort
> of thing.
> Not to say there aren't terrible API designs out there, but D doesn't make
> terrible-api-design-by-default a feature.
> Stuff like virtual is the sort of thing that only gets addressed when it is
> reported by a user that cares, and library authors are terribly reluctant to
> implement a breaking change because some user reported it. I know this from
> experience.
> I can say with confidence, poor API design has caused me less problems than
> virtual in my career.
>
> Can you honestly tell me that you truly believe that library authors will
> consider, as a matter of common sense, the implications of virtual (the silent
> default state) in their api?
> Do you truly believe that I'm making a big deal out of nothing; that I will
> never actually, in practise, encounter trivial accessors and properties that
> can't inline appearing in my hot loops, or other related issues.
>
> Inline-ability is a very strong API level performance influence, especially in a
> language with properties.
>
> Most programmers are not low-level experts, they don't know how to protect
> themselves from this sort of thing. Honestly, almost everyone will just stick
> with the default.


I find it incongruous to take the position that programmers know all about 
layout for performance and nothing about function indirection? It leads me to 
believe that these programmers never once tested their code for performance.

I know what I'm doing, and even I, when I don't test things, always make some 
innocuous mistake that eviscerates performance. I find it very hard to believe 
that final-by-default will fix untested code.

And the library APIs still are fixable. Consider:

     class C {
         void foo() { ... }
     }

and foo() needs to be final for performance, but we don't want to break existing 
users:

     class C {
         void foo() { foo2(); }
         final void foo2() { ... }
     }