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
