On 12/1/2012 1:53 AM, Andrei Alexandrescu wrote:
> On 11/29/12 9:39 PM, Walter Bright wrote:
>> On 11/30/2012 1:17 AM, Andrei Alexandrescu wrote:
>>> A possibly better approach would be e.g. to do a simple analysis of the
>>> static constructor's use of symbols, and use that set to decide whether
>>> two static constructors must be ordered or not.
>>
>> It's not a complete solution, since using a symbol S from module A does
>> not necessarily mean dependency on S being statically constructed in A.
>> But it would be a start.
>
>  From what I see it would solve most problems there are out there, 100%
> automatically, without any syntax addition, and without any downside risk.

I don't know that it will solve them 100%, because it will have to be conservative, but I think this is definitely the next step.

For example, in module a:

    int x;
    static this() { x = 3; }
    int foo() { return 2; }

Now, in our module b:

    import a;
    int y;
    static this() { y = a.foo(); }

You might think, aha! this does not depend on b's static this(), so I can construct in any order. The trouble is, though, that D is a separately compiled language, and changing b.foo() to:

    int foo() { return x; }

will not change the object file of b, and the bug will go unnoticed.

Essentially, it must work like purity inference. The inference works only for functions where the source must be available - lambdas and function templates. For other functions, the conservative view must be taken that the function might depend on a static constructor.

Note that even detecting the existence or not of a static constructor in module a is not sufficient to determine if b's constructor depends on it, as the maintainer may add one later.

To sum up, I don't think it is at all clear that this will solve 100% of the issue, but it is a big step towards that and may reduce the problem to only a rare annoyance that is more easily worked around.

On 11/30/12 22:52, Walter Bright wrote:
> On 12/1/2012 1:53 AM, Andrei Alexandrescu wrote:
>> On 11/29/12 9:39 PM, Walter Bright wrote:
>>> On 11/30/2012 1:17 AM, Andrei Alexandrescu wrote:
>>>> A possibly better approach would be e.g. to do a simple analysis of the static constructor's use of symbols, and use that set to decide whether two static constructors must be ordered or not.
>>>
>>> It's not a complete solution, since using a symbol S from module A does not necessarily mean dependency on S being statically constructed in A. But it would be a start.
>>
>>  From what I see it would solve most problems there are out there, 100%
>> automatically, without any syntax addition, and without any downside risk.
> 
> I don't know that it will solve them 100%, because it will have to be conservative, but I think this is definitely the next step.
> 
> For example, in module a:
> 
>     int x;
>     static this() { x = 3; }
>     int foo() { return 2; }
> 
> Now, in our module b:
> 
>     import a;
>     int y;
>     static this() { y = a.foo(); }
> 
> You might think, aha! this does not depend on b's static this(), so I can construct in any order. The trouble is, though, that D is a separately compiled language, and changing a.foo() to:

[ I fixed b.foo -> a.foo above ]

> 
>     int foo() { return x; }
> 
> will not change the object file of b, and the bug will go unnoticed.

No, 'b' imports 'a', so if 'a' changes, 'b' has to be recompiled.

artur

On 12/1/2012 9:54 PM, Artur Skawina wrote:
> No, 'b' imports 'a', so if 'a' changes, 'b' has to be recompiled.

That's a good point, I'll have to think about it some more.