Fixing cyclic import static construction problems

[Jacob Carlborg]

On 2012-11-29 19:17, deadalnix wrote:

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

BTW, how does Java handle this? And C# if it has something similar.

-- 
/Jacob Carlborg