The future of UDAs.

[Artur Skawina]

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