cyclic redundancy

[Mr.Bingo]

I have static this scattered throughout. Some are module static 
this and some are struct and class.


In a test case I have reduced to a struct that uses a static this 
and I get a cycle... even though, of course, the static this does 
nothing accept internal things.

It is very annoying to have to hack these cycles. while they can 
be bypassed for testing but production requires passing a runtime 
argument which is useless for distribution to users.

The cyclic testing is so ignorant that it effectively makes using 
any static this with any type of complex importing impossible, 
even though no cycles actually exist.


Something new has to be done.

I propose that some way be made to disable a static this from 
being included in the testing:

@NoCyclicRedundancyCheck static this()
{

}

I'm not sure if attributes will persist at runtime though. Any 
method is better than what we have now which essentially prevents 
all static this usage because one can't guarantee that the future 
won't create a cycle and then the program will break with no easy 
fix.