"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!

Reply via email to