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.
