We faced a bug that module static constructors don't work with cyclic imports. Currently it's fixed with a dirty hack which is not really acceptable. Is there any chance for this to be fixed?

On Fri, Feb 27, 2009 at 12:36 PM, Eldar Insafutdinov <e.insafutdinov@gmail.com> wrote:
> We faced a bug that module static constructors don't work with cyclic imports. Currently it's fixed with a dirty hack which is not really acceptable. Is there any chance for this to be fixed?
>

I'll save Walter the trouble: come up with a reproduceable testcase if you haven't already.  It won't get fixed it he can't tell what the problem is.

Jarrett Billingsley wrote:
> On Fri, Feb 27, 2009 at 12:36 PM, Eldar Insafutdinov <e.insafutdinov@gmail.com> wrote:
>> We faced a bug that module static constructors don't work with
>> cyclic imports. Currently it's fixed with a dirty hack which is not
>> really acceptable. Is there any chance for this to be fixed?
>> 
> 
> I'll save Walter the trouble: come up with a reproduceable testcase
> if you haven't already.  It won't get fixed it he can't tell what the
>  problem is.


I'll add to that my experience is that if the test case is incomplete, then I need to guess at the rest and fill it in. Often, then the test case works, and there's a cycle of "I can't reproduce the problem" followed by the missing bit of context that was the real cause.

Then once the problem gets fixed, the reproducible test case goes into the test suite so it stays fixed.

Walter Bright Wrote:

> Jarrett Billingsley wrote:
> > On Fri, Feb 27, 2009 at 12:36 PM, Eldar Insafutdinov <e.insafutdinov@gmail.com> wrote:
> >> We faced a bug that module static constructors don't work with cyclic imports. Currently it's fixed with a dirty hack which is not really acceptable. Is there any chance for this to be fixed?
> >> 
> > 
> > I'll save Walter the trouble: come up with a reproduceable testcase
> > if you haven't already.  It won't get fixed it he can't tell what the
> >  problem is.
> 
> 
> I'll add to that my experience is that if the test case is incomplete, then I need to guess at the rest and fill it in. Often, then the test case works, and there's a cycle of "I can't reproduce the problem" followed by the missing bit of context that was the real cause.
> 
> Then once the problem gets fixed, the reproducible test case goes into the test suite so it stays fixed.

I'm sorry, my mistake - it's in specs http://www.digitalmars.com/d/1.0/module.html

>Cycles (circular dependencies) in the import declarations are allowed as long  as not both of the modules contain static constructors or static destructors.  Violation of this rule will result in a runtime exception.

Now we have to make a manual init function called from class constructors. I understand that allowing static consructors with cyclic imports will make order of their execution undefined, but this is acceptable and actually semantically doesn't break the idea of cyclic imports. Otherwise in my opinion this behavior is inconsistent..

Eldar Insafutdinov wrote:
> Now we have to make a manual init function called from class
> constructors. I understand that allowing static consructors with
> cyclic imports will make order of their execution undefined, but this
> is acceptable and actually semantically doesn't break the idea of
> cyclic imports. Otherwise in my opinion this behavior is
> inconsistent..

One of the goals of D is to eliminate undefined behavior wherever possible. In C++, the undefined order of static construction was a source of many porting problems. I think it's better in the long run to have a defined order, even if it means having to reorganize the code a bit.

Walter Bright Wrote:

> Eldar Insafutdinov wrote:
> > Now we have to make a manual init function called from class constructors. I understand that allowing static consructors with cyclic imports will make order of their execution undefined, but this is acceptable and actually semantically doesn't break the idea of cyclic imports. Otherwise in my opinion this behavior is inconsistent..
> 
> One of the goals of D is to eliminate undefined behavior wherever possible. In C++, the undefined order of static construction was a source of many porting problems. I think it's better in the long run to have a defined order, even if it means having to reorganize the code a bit.

in our case resources we are initializing are unrelated to the modules we are importing. and semantically the code is placed in modules as it should be.

Eldar Insafutdinov wrote:
> in our case resources we are initializing are unrelated to the
> modules we are importing. and semantically the code is placed in
> modules as it should be.

True, often there isn't an actual dependency on the order, but the compiler can't tell that.

On Fri, Feb 27, 2009 at 5:07 PM, Walter Bright <newshound1@digitalmars.com> wrote:
> Eldar Insafutdinov wrote:
>>
>> in our case resources we are initializing are unrelated to the modules we are importing. and semantically the code is placed in modules as it should be.
>
> True, often there isn't an actual dependency on the order, but the compiler can't tell that.

I was going to say "can't it?" but then remembered separate compilation.

Sigh.  I think the separate compilation paradigm, at least as designed for C and C++, has to go the way of the dodo for lots of cool things to be made possible.  The thread on .D about not being able to non-virtualize methods in the face of separate compilation is another example.

Eldar Insafutdinov wrote:

> We faced a bug that module static constructors don't work with cyclic imports. Currently it's fixed with a dirty hack which is not really acceptable. Is there any chance for this to be fixed?

IMO it is the cyclic import that is the bug ;)

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango

Lars Ivar Igesund wrote:
> Eldar Insafutdinov wrote:
> 
>> We faced a bug that module static constructors don't work with cyclic
>> imports. Currently it's fixed with a dirty hack which is not really
>> acceptable. Is there any chance for this to be fixed?
> 
> IMO it is the cyclic import that is the bug ;)

Maybe all cyclic dependency bugs are on purpose, to teach people not to use this evil D feature? Yeah, that must it be. I can't explain why else these bugs/issues aren't fixed, and why people only reply with incredibly useful statements like "but you shouldn't use this feature anyway!".

Broken features should be either fixed or removed. This half-assedness about it isn't really going to help D.