Fixing cyclic import static construction problems

[deadalnix]

On Saturday, 1 December 2012 at 12:08:10 UTC, Artur Skawina wrote:
> The key words are "known" and "initialized". IOW
>
>    const int a = 42;
>
> doesn't add a dep, but
>
>   const int a;
>
> does.
>
> /Modifying/ initialized const data from a mod ctor is (and 
> should be) illegal.
>

That make sense.

> D's pure isn't enough, because it will allow accesses to 
> external immutable
> data - which can be modified by a mod ctor. But like i said - 
> this might not be
> a problem in practice, as it's just about the cross-module 
> non-ctfeable, but
> truly pure function calls inside mod ctors - is this really 
> something that occurs
> often enough?
>

Ho yes, this make sense too. CTFEable is still too restrictive 
but pure isn't enough.

> I'm not sure what assertion you think is false, but 
> theoretically it /is/ possible
> to figure out the deps at runtime, even w/o any hints. Think 
> valgrind. But it's
> a very bad idea, with a significant runtime cost (not as bad as 
> valgrind since you
> can figure out some things statically, but determining the 
> order alone would already
> be too slow for larger projects with many symbols and deps.)
>

The assertion is that it must be done at runtime. It is obviously 
doable at runtime, but complicated. I think that most of it can 
be done at compile time.