Final by default?

[Walter Bright]

On 3/14/2014 9:02 PM, Manu wrote:
> That said, function inlining is perhaps the single most important API level
> performance detail, and especially true in OO code (which advocates
> accessors/properties).

I find it peculiar to desire a 'final accessor'. After all,

     class C {
         int x;
         final int getX() { return x; } <= what the heck is this function for?
     }

The only reason to have an accessor function is so it can be virtual. If 
programmers are going to thoughtlessly follow rules like this, they might as 
well follow the rule:

     class C { final:


> Compile some release code without -inline and see what the performance
> difference is,

I'm well aware of the advantages of inline.


> The length you're willing to go to to resist a relatively minor breaking change,

It's a major breaking change. It'll break nearly every D program out there that 
uses classes.


> I understand that you clearly don't believe in this change, and I grant that is
> your prerogative, but I really don't get why... I just can't see it when
> considering the balance.

You may not agree with me, but understanding my position shouldn't be too hard. 
I've expounded at length on it.


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

I thought I was clear in that I believe it is a pipe dream to believe that code 
with nary a thought given to performance is going to be performant.

Besides, they don't have to consider anything or have any sense. Just blindly do 
this:

      class C { final:


> Or you don't consider that to be something worth worrying about, ie, 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?

I think we're just going around in circles. I've discussed all this before, in 
this thread.