The future of UDAs.

[Walter Bright]

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.