Review of Andrei's std.benchmark

["Øivind"]

On Friday, 21 September 2012 at 20:43:13 UTC, Jonathan M Davis 
wrote:
> On Friday, September 21, 2012 15:59:31 Andrei Alexandrescu 
> wrote:
>> On 9/19/12 4:11 PM, "Øivind" wrote:
>> > New question for you :)
>> > 
>> > To register benchmarks, the 'scheduleForBenchmarking' mixin 
>> > inserts a
>> > shared static initializer into the module. If I have a 
>> > module A and a
>> > module B, that both depend on eachother, than this will 
>> > probably not
>> > work..? The runtime will detect the init cycle and fail with 
>> > the
>> > following error:
>> > 
>> > "Cycle detected between modules with ctors/dtors"
>> > 
>> > Or am I wrong now?
>> 
>> I think you have discovered a major issue. Ideas on how to 
>> attack this?
>
> Some of us have been asking for ages for the ability to mark a 
> static
> constructor as not depending on anything so that the runtime 
> _doesn't_ think
> that there's a circular dependency, but Walter has been against 
> the idea when
> it's been brought up. That would _really_ help here.
>
> Without redesigning std.benchmark so that it doesn't use static 
> constructors,
> I don't know how you can fix that. Normally, if you really need 
> a static
> constructor, you go through the pain of creating a separate 
> module which does
> the initialization for you (like std.stdio does). But that 
> won't work in this
> case, because you're mixing it in. So, unless you can redesign 
> it so that
> std.benchmark doesn't require static constructors, it may have 
> to be a
> limitation of std.benchmark that it can't be used where it 
> would create a
> circular dependency.
>
> Unfortunately, the circular dependency issue makes static 
> constructors almost
> useless outside of isolated cases, even though they rarely 
> actually have
> circular dependencies. It's one of the few places in D that I'd 
> say that
> there's a major design flaw.
>
> - Jonathan M Davis


Is there a way to solve the dependency issue without forbidding 
static constructors in modules with cyclic dependencies?

I.e. for two modules with static init referencing eachother, an 
analysis of the static init code could be used to detect circular 
dependencies instead of the import statements?