DMD 1.038 and 2.022 releases

[John Reimer]

Hello Lars,

> bearophile wrote:
> 
>> Walter Bright:
>> 
>>> Excess isn't the problem, I want to see if import cycles is.
>>> 
>> Generally all the modules in my dlibs import each other. This is
>> nearly unavoidable, if a module contains string functions, and
>> another one contains math stuff, the string module will want to use
>> some math stuff and the math module may need string representations
>> and processing. In the D specs I haven't seen an advice to not use
>> cyclic imports, so I don't want such compiler flag, I prefer a
>> compiler able to manage such cyclic imports efficiently.
>> 
> Cyclic imports is very often a sign of bad design, it typically mean
> (if it is unavoidable), that the modules shouldn't be separated in the
> first place. And in D it _is_ a bad idea because static initialization
> cannot depend on each other, that is cyclic imports of modules with
> static ctors.
> 


And yet it appears practically unavoidable in D in many situations, especially 
in porting software that with C, Java, or C++ heritage.  Since other languages 
don't necessarily have the same module/package concept (except perhaps Java 
is the closest), porting such projects over to D inevitably triggers the 
cyclic dependency problem.  The problem does indeed exacerbate when static 
initialization is thrown into the equation.

One would have to build a D project from scratch in order to avoid it (eg 
Tango).  The majority of projects, however, are going to be based on ported 
code.  Thus, "bad design" becomes somewhat meaningless practically speaking, 
although I certainly wish there were an easy solution to the cyclic imports 
other than including all files in the same module. :)

-JJR