virtual-by-default rant

[Dmitry Olshansky]

On 19.03.2012 2:17, Artur Skawina wrote:
> On 03/18/12 15:37, Dmitry Olshansky wrote:
>> On 18.03.2012 5:23, Manu wrote:
>>> The virtual model broken. I've complained about it lots, and people
>>> always say "stfu, use 'final:' at the top of your class".
>>>
>>> That sounds tolerable in theory, except there's no 'virtual' keyword to
>>> keep the virtual-ness of those 1-2 virtual functions I have... so it's
>>> no good (unless I rearrange my class, breaking the logical grouping of
>>> stuff in it).
>>> So I try that, and when I do, it complains: "Error: variable
>>> demu.memmap.MemMap.machine final cannot be applied to variable",
>>> allegedly a D1 remnant.
>>> So what do I do? Another workaround? Tag everything as final individually?
>>>
>>> My minimum recommendation: D needs an explicit 'virtual' keyword, and to
>>> fix that D1 bug, so putting final: at the top of your class works, and
>>> everything from there works as it should.
>>
>> Following this thread and observing that you don't trust optimizer and compiler in many cases or have to double check them anyway, I have a suggestion: do virtual dispatch by hand via func-pointer table and use structs.
>>
>> I'm serious, with a bit of metaprogramming it wouldn't be half bad, and as a bonus you don't have to pay for a monitor field per object as classes do, and in general less compiler magic to keep track of. You also gain the ability to fine tune their layout, the performance maniac side of yours must see the potential it brings :)
>
> I was going to suggest the very same thing - but there are (at least) two problems
> with that approach:
>
> 1) pass-by-value -- it's dangerous, ugly to work-around (and compiler bugs don't
>     help, like the one where just having a "this(this)" causes problems); the
>     workarounds also have compiler/ABI issues (like the 'File' case posted in D.learn
>     some time ago, or GDC not passing/returning the pseudo-refs in registers)

GDC not passing pseudo-refs in registers is cleanly a non-issue, in a 
sense, that it's not a good excuse at all, as well the other bugs.
All in all, nobody is going to kill you if in performance sensitive code 
you'd use pointers:

BigStruct* my_big = allocateSomewhere(...ctor_args...); //ultimately 
using emplace


> 2) no inheritance. ie 'struct A{}; struct B{A super; alias super this;}' cannot be
>     written as just 'struct B:A {}' - which would not be just syntax sugar, but also
>     allow (more) implicit conversions, (explicit) function overrides etc.
>

Template mixins? I envision:
struct Foo{
	mixin Inherit!(Bar);
}

I see that it is not a cake-walk but acceptable for the special nature 
of requirements.

> So - yes, D structs should be enough for everything, but right now they're still
> missing some required basic features. Ideally "class" would just be sugar, and
> everything should be expressible using just structs - obviously in a much more
> verbose, but 100% compatible way (incl vtables, monitors etc)

Yes, that the point. And if one doesn't like this kind of compiler 
sugar, he is free to synthesize Xylitol.



-- 
Dmitry Olshansky