Fixing cyclic import static construction problems

[Max Samukha]

On Thursday, 29 November 2012 at 15:18:11 UTC, Paulo Pinto wrote:
> On Thursday, 29 November 2012 at 12:04:28 UTC, Max Samukha 
> wrote:
>> On Thursday, 29 November 2012 at 11:39:20 UTC, Paulo Pinto 
>> wrote:
>>> On Thursday, 29 November 2012 at 03:19:55 UTC, Andrei 
>>> Alexandrescu wrote:
>>>> On 11/28/12 9:34 PM, Walter Bright wrote:
>>>>> For discussion:
>>>> [snip]
>>>>
>>>> I'd say we better finish const, immutable, and shared first.
>>>>
>>>> Andrei
>>>
>>> +1
>>>
>>> Fully agree.
>>>
>>> Cyclic imports are a minor nuisance that can be easily 
>>> solvable with better code architecture.
>>
>> Show me please how to solve that problem easily with 
>> acceptable results, would you?
>
> You just need to have a better architecture.
>
> In 20 years of software development experience I never found a 
> case were this wasn't possible.

That's an argument from authority, sorry.

>
> Maybe you care to provide an example?
>

The general problem is constructing global data structures based 
on data introspected at compile-time.

My specific problem is extending scarce runtime type information 
provided by the language with something usable for runtime 
reflection. With lots of detail omitted:

module reflect;

Meta[string] metas;
mixin template Reflect(alias object) {
     static this()
     {
         auto m = meta!(object);
         metas[m.fullName] ~= m;
     }
}


module a;
import reflect;

struct S
{
}
mixin Reflect!S;

The meta-object for S is automatically made available at runtime 
through the global metas array. Note that we do not want to force 
the user to register the meta-object manually because then it 
would not be a "better architecture".

The important (Andrei somehow thinks it is not) requirement is 
there must not be circular dependency issues for the users of the 
"reflect" module.