The future of UDAs.

Artur Skawina art.08.09 at gmail.com
Sat Dec 1 02:54:01 PST 2012


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


More information about the Digitalmars-d mailing list