std.reflection prototype

[bitwise via Digitalmars-d]

On Thursday, 2 April 2015 at 06:57:25 UTC, Jacob Carlborg wrote:
> 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/mfcgj3$12a0$1@digitalmars.com
> [2] http://forum.dlang.org/thread/mfci6o$13oa$1@digitalmars.com
> [3] http://forum.dlang.org/thread/ks1brj$1l6c$1@digitalmars.com
> [4] http://forum.dlang.org/thread/kok86c$126l$1@digitalmars.com

Ok, I think I understand what you're suggesting now, which is 
that you want a library to be able to override RTInfo in order to 
add it's own metadata to all types, which raises the question, 
what if more than one library wants to add metadata? And I think 
this question was addressed by the suggestion of the AA for 
RTInfo where the module's fully qualified name was the key, which 
won't work because of separate compilation... right?

So in my case I could just update my RTInfo to generate a 
reflection for each type, and make it accessible using a UFC or 
something.

If I understand correctly though, the idea has been dismissed as 
being impossible due to separate compilation, right? Is there any 
leads on this at this point?