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...
Thoughts?
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'
-Steve
