On 2012-11-28 20:57, Manu wrote:

> Well fortunately that hasn't happened yet... That does worry me though.
> I can't imagine a work-around if that comes up.

std.stdio uses an ugly workaround. It has an extern(C) function which is called from the shared static constructor in stdiobase.d:

https://github.com/D-Programming-Language/phobos/blob/master/std/stdio.d#L2357

https://github.com/D-Programming-Language/phobos/blob/master/std/stdiobase.d

-- 
/Jacob Carlborg

On Wednesday, 28 November 2012 at 20:14:52 UTC, Jacob Carlborg wrote:
> On 2012-11-28 20:57, Manu wrote:
>
>> Well fortunately that hasn't happened yet... That does worry me though.
>> I can't imagine a work-around if that comes up.
>
> std.stdio uses an ugly workaround. It has an extern(C) function which is called from the shared static constructor in stdiobase.d:
>
> https://github.com/D-Programming-Language/phobos/blob/master/std/stdio.d#L2357
>
> https://github.com/D-Programming-Language/phobos/blob/master/std/stdiobase.d

Doesn't go with mixins.

On 11/29/2012 3:23 AM, Max Samukha wrote:
> That is a problem for anyone who builds a library for general use.

I don't see how any library for general use would be importing user modules, so there shouldn't be a circular import dependency between user modules and library modules.

On 11/29/2012 7:11 AM, Max Samukha wrote:
> Just a random thought: what if the compiler didn't check cycles for
> modules that define only static ctors attributed with @system/@trusted?


It's a good idea to have a way of saying a static constructor has no dependencies on imports, but I don't think @system implies that, although such a static constructor would have to be @trusted/@system. (Since the compiler could not verify the absence of such dependencies.)

It also may be possible to:

    pragma(no_import_dependencies)

or something like that, which also would put the onus on the programmer to make sure there really aren't any.

On 11/28/2012 11:46 PM, Walter Bright wrote:
> On 11/29/2012 3:23 AM, Max Samukha wrote:
>> That is a problem for anyone who builds a library for general use.
>
> I don't see how any library for general use would be importing user
> modules, so there shouldn't be a circular import dependency between user
> modules and library modules.
>


// ---

module a;
import b;
import lib;

mixin Lib;

// ---

module b;
import a;
import lib;

mixin Lib;

// ---

On Wednesday, 28 November 2012 at 22:46:47 UTC, Walter Bright wrote:
> On 11/29/2012 3:23 AM, Max Samukha wrote:
>> That is a problem for anyone who builds a library for general use.
>
> I don't see how any library for general use would be importing user modules, so there shouldn't be a circular import dependency between user modules and library modules.

module library;
shared string[] registry;

mixin template RegisterSomething(alias something)
{
    shared static this() { registry ~= something.stringof; }
}

----
module user_b;
import user_a;
import library;

int y;
mixin RegisterSomething!y;

----
module user_a;
import user_b;
import library;

int x;
mixin RegisterSomething!x;


We have:
        library
     /            \
user_a <-circle-> user_b

That is why I am saying that we are imposing a certain structure (no circular imports) on the user of our library. For example, if the user prefers (or has to use, in my case) a class-per-module structure, circular dependencies between user modules are practically unavoidable and the library cannot be used there.

On Wednesday, 28 November 2012 at 22:51:30 UTC, Walter Bright wrote:
> On 11/29/2012 7:11 AM, Max Samukha wrote:
>> Just a random thought: what if the compiler didn't check cycles for
>> modules that define only static ctors attributed with @system/@trusted?
>
>
> It's a good idea to have a way of saying a static constructor has no dependencies on imports, but I don't think @system implies that, although such a static constructor would have to be @trusted/@system. (Since the compiler could not verify the absence of such dependencies.)

I agree.

>
> It also may be possible to:
>
>     pragma(no_import_dependencies)
>
> or something like that, which also would put the onus on the programmer to make sure there really aren't any.

Pragmas are being superseded by attributes? Maybe a shorter equivalent of @no_import_dependencies or something?

Be it pragma or attribute, it would be welcome.

On Wednesday, 28 November 2012 at 23:41:37 UTC, Timon Gehr wrote:
> On 11/28/2012 11:46 PM, Walter Bright wrote:
>> On 11/29/2012 3:23 AM, Max Samukha wrote:
>>> That is a problem for anyone who builds a library for general use.
>>
>> I don't see how any library for general use would be importing user
>> modules, so there shouldn't be a circular import dependency between user
>> modules and library modules.
>>
>
>
> // ---
>
> module a;
> import b;
> import lib;
>
> mixin Lib;
>
> // ---
>
> module b;
> import a;
> import lib;
>
> mixin Lib;
>
> // ---

Didn't see your post, sorry.

On 11/29/2012 10:41 AM, Timon Gehr wrote:
> // ---
>
> module a;
> import b;
> import lib;
>
> mixin Lib;
>
> // ---
>
> module b;
> import a;
> import lib;
>
> mixin Lib;
>
> // ---

Ok, ya got me!

On Thursday, November 29, 2012 01:07:56 Max Samukha wrote:
> > It also may be possible to:
> > pragma(no_import_dependencies)
> > 
> > or something like that, which also would put the onus on the programmer to make sure there really aren't any.
> 
> Pragmas are being superseded by attributes? Maybe a shorter equivalent of @no_import_dependencies or something?
> 
> Be it pragma or attribute, it would be welcome.

That's understatement. The circular dependency issues with static constructors is _really_ annoying, particularly since they almost never actually represent a circular dependency. Having it check is fine, but there really should be a way to indicate that there is no such dependency. Without it, I don't think that it's even possible to reasonably do stuff like what Andrei is trying to do with std.benchmark without it (it mixes a static constructor into the module that your benchmarking).

I don't really care whether it's done with an attribute or a pragma, but pragmas are supposed to be potentially compiler-specific as opposed to being part of the language, so I'd think that an attribute would make more sense.

- Jonathan M Davis