On 19/12/2016 5:53 AM, Andrei Alexandrescu wrote:
Compulsive ModuleInfo generation seems to be a drag. I'm not very
familiar with the particulars but my understanding is ModuleInfo is
needed for (a) Object.factory and (b) finding and running unittests.
Walter and I think Object.factory was a mistake and we'd like to make it
opt-in long term (either by means of a build flag or a class attribute).
Until then, a very nice step forward is to NOT generate ModuleInfo if a
module introduces no class.
For unittests, I figure things like static introspection should make it
easier to enumerate and run unittests without a need for ModuleInfo.
What other issues/opportunities do you see related to ModuleInfo?
Thanks,
Andrei
I've been toying with the idea of completely overhauling TypeInfo.
Here is the gist of what I want:
- -typeinfo=low/low-min/normal/high/none
None is pretty much -betterC
Low would be unittests + module constructors
Low-min would be like low but with only the fields that is needed
Normal is what we have now more or less
High of course includes all the goodies like class fields and methods
reflection
- Full class + struct + union symbol reflection, so fields uda's ext.
My feeling is D really is two different languages.
An application one and a system one.
The difference isn't much. It really comes down to how hooked into
druntime it is and so TypeInfo.
From there we just need to remove all language features that require
druntime or allow a way to you know, clear deallocation path.
