On Fri, 14 Feb 2014 09:07:35 -0500, Daniel Murphy <yebbliesnos...@gmail.com> wrote:

"1100110"  wrote in message news:ldl6v6$255r$1...@digitalmars.com...

I dont know enough about TLS to comment really. Thoughts?

It's probably platform dependent, I guess it should work everywhere that C supports TLS.

I'm 90% sure that MacOS does not natively support TLS, and uses the core.Thread class to store it.

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.

unittests are out as well.

Most likely.

Yes, this also depends on moduleinfo, like static ctor/dtor.

I'm unsure how useful classes will be without a GC or the runtime...
I'd be fine with then being disabled.

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.

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'


Reply via email to