January 05, 2012
On 1/5/2012 1:13 AM, Manu wrote:
> In 15 years I have never once overridden a non-virtual function, assuming it was
> virtual, and wondering why it didn't work... have you?

Yes, I have. With a complex inheritance hierarchy, I was doing the optimization thing and removing 'virtual' from members that didn't get overridden. Then, some long time later, I'd add an override and forget to put the 'virtual' back on the original.

Very strange behavior of my program would result.

Even worse, frankly I defy anyone to look at a complex C++ inheritance hierarchy and say with certainty that you've verified that there are no overrides of non-virtual functions in it.

> I've never even heard a story of a colleague, or even on the net of that ever
> happening (yes, I'm sure if I google specifically for it, I could find it, but
> it's never appeared is an article or such)... but I can point you at almost
> daily examples of junior programmers making silly mistakes that go un-noticed by
> their seniors. Especially common are mistakes in declaration where declaration
> attributes don't change whether the program builds and works or not.

That is the case with overriding a non-virtual function - the compiler will compile it anyway, and most of the time it will work. That's what makes it so eeevil.


> It seems to me the decision is that of sacrificing a real and common problem
> case with frequent and tangible evidence, for the feeling that the language is
> defined to do the 'right' thing?

The right thing should be the default.


>     It's also true that D's design makes it possible for a compiler to make
>     direct calls if it is doing whole-program analysis and determines that there
>     are no overrides of it.
>
>
> This is only possible with whole program optimisation, and some very crafty code
> that may or may not ever be implemented, and certainly isn't dependable from
> compiler vendor 'x'.. There would simply be no problem in the first place if the
> default was declared the other way around, and the compiler would need none of
> that extra code, and there are no problems of compiler maturity.
> Surely this sort of consideration is even more important for an open source
> project with a relatively small team like D than it is even for C++?

I feel the correct decision was made. But regardless, there's no way to reverse that decision, as it will break most every D program in existence, and be a HUGE annoyance to everyone who has D code.

January 05, 2012
On 1/5/2012 1:02 AM, Manu wrote:
> My argument is that even IF the compiler some day attempts to make vector
> optimisations to float[4] arrays, the raw hardware should be exposed first, and
> allow programmers to use it directly. This starts with a language defined
> (platform independant) v128 type.

Manu, I appreciate your expertise in this manner, which I lack. I think you've made a great case. Can you flesh this out with more specific suggestions on what language changes would work best?
January 05, 2012
>
> That is the case with overriding a non-virtual function - the compiler will compile it anyway, and most of the time it will work. That's what makes it so eeevil.


I saw today, or last night, someone suggesting a keyword to make
non-virtual override explicit, and error otherwise. Which actually sounded
like a really good idea to me, and also addresses this problem.
I think a combination of not-virtual-by-default, and an explicit
non-virtual override keyword would cover your concern, and also minimise
the use of virtual functions. Sounds perfect to me ;)
Overriding a non-virtual is actually very rare, and probably often
unintended... I really like the idea of a keyword to make this rare use
explicit.


> It seems to me the decision is that of sacrificing a real and common
>> problem
>> case with frequent and tangible evidence, for the feeling that the
>> language is
>> defined to do the 'right' thing?
>>
>
> The right thing should be the default.
>

But I fundamentally disagree your choice is 'right'.. This is obviously
subjective, so I don't think that's a fair assertion.
The problem was obviously not completely defined, and not addressed
entirely.. I think the proposal above sounds like a better solution all
round, it addresses everyones concerns, and adds a nice little safety bonus
for rare non-virtual overriding ;)
But as I've previously said, I understand this can't change now, I've let
it go :P


January 05, 2012
On Jan 5, 2012, at 12:36 PM, Manu wrote:

> On 5 January 2012 21:41, Sean Kelly <sean@invisibleduck.org> wrote: On Jan 5, 2012, at 10:02 AM, Manu wrote:
> >
> > That said, this is just one of numerous issues myself and the OP raised. I don't know why this one became the most popular for discussion... my suspicion is that is because this is the easiest of my complaints to dismiss and shut down ;)
> 
> It's also about the only language change among the issues you mentioned.  Most of the others are QOI issues for compiler vendors.  What I've been curious about is if you really have a need for the performance that would be granted by these features, or if this is more of an idealistic issue.
> 
> I think they are all language requests. They could be implemented by 3rd party compilers, but these things are certainly nice to standardise in the language, or you end up with C, which is a mess I'm trying to escape.

It's a grey area I suppose.  Half of the features you list don't change the language, they simply allow the compiler to make optimizations it otherwise couldn't.  I suppose the D way would be to make them '@' prefixed and provide some means for having the compiler ignore them if it didn't recognize them.  This wouldn't fragment the language so much as make generated code more efficient on supporting platforms.


> Of the topics been discussed:
>   * vector type - I can't be expected to write a game without using the vector hardware... I'd rather use a portable standardised type than a GDC extension. Why the resistance? I haven't heard any good arguments against, other than some murmurings about float[4] as the official syntax, which I gave detailed arguments against.

Could a vector type be defined in the library?  Aside from alignment, there doesn't seem to be anything that requires compiler support.  Or am I missing something?


>   * inline asm supporting pseudo regs - As an extension of using the vector hardware, I'll need inline asm, and inline assembly without pseudo regs is pretty useless... it's mandatory that the compiler shedule the register allocation otherwise inline asm will most likely be an un-optimisation. If D had pseudo regs in its inline assembler, it would make it REALLY attractive for embedded systems programmers.

This would certainly be nice.  When I drop into ASM I generally could care less about which actual register I use.  I just want to call something specific.


>     In lieu of that, I need to use opcode intrinsics instead, which I believe GDC exposes, but again, I'm done with C and versioning (#ifdef-ing) every compiler I intend to use. Why not standardise these things? At least put the intrinsics in the standard lib...
> 
>   * __restrict - Not a deal breaker, but console game dev industry uses this all the time. There are countless articles on the topic (many are private or on console vendor forums). If this is not standardised in the language, GDC will still expose it I'm sure, fragmenting the language.
> 
>   * __forceinline - I'd rather have a proper keyword than using tricks like mixins and stuff as have been discussed. The reason for this is debugging. Code is not-inlined in debug builds, looks&feels like normal code, can still evaluate, and step like regular code... and guarantee that it inlines properly when optimised. This just saves time; no frills debugging.

I'd say these are QOI issues, as above.


>   * multiple return values - This is a purely idealistic feature request, but would lead to some really nice optimisations while retaining very tidy code if implemented properly. Other languages support this, it's a nice modern feature... why not have it in D?

I can see the ABI rules for this getting really complicated, much like how parameter passing rules on x64 are insanely complex compared to x32.  But I agree that it would be a nice feature to have.


> I couldn't release the games I do without efficient use of vector hardware and __restrict used in appropriate places. I use them every day, and I wouldn't begin a project in D without knowing that these features are supported, or are definitely coming to the language.

I know it's a major time commitment, but the best way to realize any new feature quickly is to create a pull request.  Feature proposals have a way of being lost if they never extend beyond this newsgroup.
January 05, 2012
On Jan 5, 2012, at 1:03 PM, Manu wrote:

> That is the case with overriding a non-virtual function - the compiler will compile it anyway, and most of the time it will work. That's what makes it so eeevil.
> 
> I saw today, or last night, someone suggesting a keyword to make non-virtual override explicit, and error otherwise. Which actually sounded like a really good idea to me, and also addresses this problem.

I think the override keyword fits here, though in reverse.
January 05, 2012
On 5 January 2012 22:47, Walter Bright <newshound2@digitalmars.com> wrote:

> On 1/5/2012 1:02 AM, Manu wrote:
>
>> My argument is that even IF the compiler some day attempts to make vector
>> optimisations to float[4] arrays, the raw hardware should be exposed
>> first, and
>> allow programmers to use it directly. This starts with a language defined
>> (platform independant) v128 type.
>>
>
> Manu, I appreciate your expertise in this manner, which I lack. I think you've made a great case. Can you flesh this out with more specific suggestions on what language changes would work best?
>

Love to. I'll give it some thorough thought. There's more details than I think most would expect...


January 05, 2012
On 1/5/2012 8:49 AM, Manu wrote:
> I also wonder if the D language provides some opportunities for optimisation
> that aren't expressible in other languages,

There are some. One that is currently being exploited by the optimizer and back end is the existence of pure functions.

> and therefore may not already have
> an expression in the GCC back end... so I can imagine some of future
> optimisations frequently discussed in this forum won't just magically appear
> with GCC/LLVM maturity. I can't imagine Iain and co extending the GCC back end
> to support some obscure D optimisations happening any time soon.

Right.


> At some level I'd like to think people would accept the word of a seasoned game
> engine dev who's genuinely interested in adopting the language for that sort of
> work, but I completely understand those who are skeptical. ;)

I'm interested in hearing more. (The virtual thing can't change.)
January 05, 2012
On 1/5/2012 10:02 AM, Manu wrote:
> That said, this is just one of numerous issues myself and the OP raised. I don't
> know why this one became the most popular for discussion... my suspicion is that
> is because this is the easiest of my complaints to dismiss and shut down ;)

That's a common phenomena, known as bikeshedding. Issues that are easy to understand, everyone will weigh in. The hard ones require an investment of effort to understand, and few will do it.
January 05, 2012
On 1/5/2012 3:58 AM, Manu wrote:
> How is this possible, when all functions are virtual, without whole program
> optimisation?

Only public non-final class member functions are virtual. Furthermore, as in C++, the compiler can sometimes determine that a virtual function is being called directly, and will do so (or inline it).
January 05, 2012
On 1/5/2012 6:06 AM, Manu wrote:
> It would also be generally nice if these concerns were acknowledged rather than
> brushed off. I'm not making problems for the sake of conversation. These are
> real issues that I encounter in my daily work.

I do appreciate your effort in making these issues known to us.