In article <chr7l5$v3p$1@digitaldaemon.com>, Walter says...
>> Or have I missed the point completely and there is some other case that's causing a problem?
>
>The problem is if A imports B, and B imports A, whose initialization code gets run first? The imports imply a dependency, so we have "A requires that B's initializers run first" coupled with "B requires that A's initializers run first." There's no resolution.

I see your point: the problem /is/ deeper than just running static ctors in order.  It also gets worse when you throw additional modules into such an "import cycle".

>The only one I can think of is that a
>module with no initializers doesn't have a requirement that the imports get
>initialized first. And I think that is always correct - that if there *is*
>such a dependency in the code, then there's something else wrong.

You're talking about the relaxed init rules already in phobos, correct? _moduleCtor2() treats modules with and without ctors differently, in the manner you prescribe.

I think there may be another way.

Perhaps mixing the two cases would be best: if the imported module doesn't have a ctor then don't worry if its flagged as 'MIctorstart', but throw an error if it has a ctor and is flagged as such.  That way you'd be able to detect init cycles regarless of the intermediate imported module types (modules with or w/o ctors).  In addition, modules w/o ctors can cycle all they want.

This is (slightly) different from the current behavior which is dependenent upon the current module type.  Instead, it relies on the /imported/ module type.

If I'm correct this would be the new behavior from this, and previously
mentioned, changes:
- 'import' and 'private import' now behave the same (new)
- all modules are included in the init sequence  (new)
- imported modules w/o ctors can participate in cyclic imports. (somewhat new)
- modules w/static ctors cannot participate in cyclic imports. (same)
- (implied) cycles of mixed module types are not allowed (new)

- Pragma
[[ eric anderton at yahoo dot com ]]

"pragma" <pragma_member@pathlink.com> wrote in message news:chsfc1$1j7d$1@digitaldaemon.com...
> If I'm correct this would be the new behavior from this, and previously
> mentioned, changes:
> - 'import' and 'private import' now behave the same (new)
> - all modules are included in the init sequence  (new)
> - imported modules w/o ctors can participate in cyclic imports. (somewhat
new)
> - modules w/static ctors cannot participate in cyclic imports. (same)
> - (implied) cycles of mixed module types are not allowed (new)

Ok, but *why* should a module that has no static ctors have a dependency on other module static ctors?

In article <chtp3c$26mj$1@digitaldaemon.com>, Walter says...
>Ok, but *why* should a module that has no static ctors have a dependency on other module static ctors?

Easy.  A module w/o any static ctors may have functions that are callable from *other* module ctors.  It may have no initalization requirements (and rightly so since it doesn't have a static ctor), but it may depend on the behavior of additional modules that in turn rely on their own static ctors to run first.

Here's a more concrete example. :)

// api.d (just an interface, so there's no module ctor here)
private import logger;
private import ilogger;

public static ILogger getDefaultLogger(){ return logger.defaultLogger; }


// ilogger.d
interface ILogger{ /*methods omitted*/}


// logger.d
private import ILogger;

class Logger: ILogger{ /*methods omitted*/ }
private Logger defaultLogger;
static this(){ defaultLogger = new Logger();


// client.d (not in the library at all)
import api.d
import ilogger.d

/** this is where it would break: getDefaultLogger() might return null **/
static this(){ api.getDefaultLogger().log("started"); }


The above example yields unpredictable results because one cannot guarantee that logger.d will be initalized before client.d.  (In fact, one cannot gaurantee that it *won't* initalize before client.d either)  If api.d, a module w/o static init code, were included in the init dependency chain, then this would run predictably and as expected.

- Pragma
[[ Eric Anderton at yahoo dot com ]]