Fixing cyclic import static construction problems

[Artur Skawina]

On 12/01/12 12:29, deadalnix wrote:
> On Saturday, 1 December 2012 at 10:54:37 UTC, Artur Skawina wrote:
>> 3) reading known initialized constant data works. That's const/immutable/enum -
>>    again, those can never become a RT dep.
> 
> const or immutable can be instanciated by another static ctor.

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.


>> 4) calling side-effect free code that does not depend on non-local state works.
>>    This is why an is-it-ctfeable check works - it will catch even the indirect deps.
>>    Yeah, it's conservative, but is has to be. A kind of 'pure-but-w/o-external-refs"
>>    thing would help further, but that can be added incrementally and may not even
>>    be necessary.
>>
> 
> pure is probably enough. CTFEable is more restrictive.

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?

>>> have nothing even close to that. Regardless, while the compiler may be able
>>> to provide additional information to the runtime, it's still the runtime that
>>> needs to figure this out and not the compiler.
>>
> 
> That is an undemonstrated assertion (and I think it is false).
> 
>> No. Would, at least, require going from per-module to per-symbol which is a *much*
>> larger change than was proposed here. I don't even want to think about the (runtime)
>> cost.
>>
> 
> This reasonning is based on the assertion above, so is meaningless until the assertion is proven to be true.

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.)

artur