On 2015-04-02 02:28, bitwise wrote:
If I'm understanding correctly, doing it this way is to avoid making
changes to the compiler, right?
I don't understand this decision because it seems that most of the
needed infrastructure is already built into ModuleInfo, and that it just
needs to be completed. It would eliminate the problem of template/code
bloat from a library like mine, and at the same time, would not require
the user to register any types.
As I said, the reason for implementing RTInfo for modules was to _not_
have to register anything.
There are other good use cases for both RTInfo and RMInfo (runtime
module info), they are a more generic solution. Two other threads about
unit testing [1], [2] is a good use case. RMInfo can be used to collect
all unit test functions and create a custom runner.
Here's [3] one example where a unit test runner makes it possible to
have CTFE unit tests. This proof of concept only scans the current
module, here RMInfo would be really handy to scan all modules.
Here's [4] one example where RTInfo is used to check virtual methods.
All virtual methods are required to be marked with @virtual.
There's a lot of missing info in ModuleInfo and TypeInfo. For example
MemberInfo_function contains no information about parameters, return
types, attributes and so on.
[1] http://forum.dlang.org/thread/[email protected]
[2] http://forum.dlang.org/thread/[email protected]
[3] http://forum.dlang.org/thread/[email protected]
[4] http://forum.dlang.org/thread/[email protected]
--
/Jacob Carlborg
