"Steven Schveighoffer" wrote in message
news:op.xa929juueav7ka@stevens-macbook-pro.local...
>> static this/~this is tougher. If it is possible for it to work, then
>> it should. I feel that this is more of a language feature.
>
> These might work with init sections, but maybe not.
No, static ctor/dtor is not a trivial mechanism. There is a runtime graph
analysis to make sure there are no cycles, and then run them in the proper
order.
I think this feature has to be disabled.
I meant that we could get something mostly working using init sections, but
it's probably not a good idea.
>> unittests are out as well.
>
> Most likely.
Yes, this also depends on moduleinfo, like static ctor/dtor.
Same with this, not worth the hack.
>
> I'll take it you've never seen how virtual functions are implemented in
> C? Classes are awesome.
This requires vtables and typeinfo. I've seen virtual functions
implemented in C (back when I wrote Xt widgets). I also think that with
D's compile-time power, one could probably recreate it using templates.
I don't want to recreate it, I want to avoid it.
The issue I have with allowing classes is the implications of classes. D
classes are infinite-lifetime, meaning requiring GC. What we would end up
with is classes written for the minimal no-gc version of D, and classes
that were written to be allocated on the GC heap in full-D. And both would
be named 'class'
This is a very good point. extern(C++) classes do not depend on druntime,
and currently do not have their destructors run by the GC!
