Fixing cyclic import static construction problems

[deadalnix]

On Thursday, 29 November 2012 at 12:17:49 UTC, Jonathan M Davis 
wrote:
> Basic features in the language require static constructors 
> (e.g. static
> variables frequently do), and some things just can't be done 
> without them.
> Andrei's std.benchmark proposal actually doesn't work, because 
> in order to do
> what it does, in needs to mixin in a static constructor and 
> static destructor
> (to set up the benchmarking and record it at the end, I 
> believe). That
> completely falls apart due to cyclical imports. It doesn't 
> actually cause any
> true circular dependencies, but it's treated as such anyway. A 
> _lot_ of us
> have run into this problem and a number of us consider it to be 
> a huge design
> problem in the language. Personally, I'd put it towards the top 
> of design
> mistakes at this point, and I'm very glad to see Walter 
> actually finally being
> willing to do something about this. In the past when I've 
> brought up similar
> solutions, he's been completely opposed to them.
>
> Yes, we have other major issues that need to be resolved, and 
> those may very
> well be of a higher priority, but this is still a very import 
> issue, and it's
> the sort of issue that can probably be implemented with minimal 
> effort. The
> main thing is getting Walter to agree to it and how it will be 
> done. Once a
> decision is made, it wouldn't surprise me if someone like Kenji 
> were able to
> get it done very quickly.
>
> - Jonathan M Davis

That is understood, but Let me explain how I see things.

We are here adding yet a new feature, however small. Nothing 
stabilize when adding new feature all the time.

The annoyance exist, is real, but is not THAT bad, and 'm pretty 
sure the proposed solution is likely to backfire. Firstly because 
a module can have several constructors, and more can be added by 
mixins. Ensuring that constructor A will not create dependancy 
cycle error may silently break other constructor of the module.

Considering the problem static constructor solve, I'd be happy to 
see some think out of the box. The way things work here may be 
broken. Many people consider that D runtime should evolve in a 
way that promote fibers and map them over system threads (this 
have many benefit : the program adapt autmatically to the 
provided hardware, yields can be introduced directly into the 
runtime or some libraries to hide IO latencies, and many other 
things), and static constructor/variables really get into the way 
(you would have to run all static constructors each time you 
start a new fiber or reset one to reuse it).

I really wish we can focus on figuring out the uses cases we have 
for static constructor and start the reflection from theses sues 
case and not from the feature itself.