static this sucks, we should deprecate it

[Ary Borenszweig]

Steven Schveighoffer wrote:
> On Thu, 28 May 2009 12:11:18 -0400, Ary Borenszweig 
> <ary at esperanto.org.ar> wrote:
> 
>> Steven Schveighoffer wrote:
>>> On Thu, 28 May 2009 11:32:19 -0400, Ary Borenszweig 
>>> <ary at esperanto.org.ar> wrote:
>>>
>>>> Unknown W. Brackets wrote:
>>>>> Probably a silly idea, but what about (or similar):
>>>>>  static this: mod.name, mod.name2, mod.name3
>>>>> {
>>>>> }
>>>>>  For a dependency list.  I may be wrong, but afaik the main 
>>>>> problems stem from either wrong order or co-dependence (which needs 
>>>>> to be solved by the programmer.)
>>>>>  At least with this, you could ask the compiler for an order, 
>>>>> potentially.  If the other modules had no static this, it could 
>>>>> ignore it, allowing future proofing.
>>>>>  But, maybe that's an ugly hack.
>>>>>  -[Unknown]
>>>>>   davidl wrote:
>>>>>> Why on earth we still let the tumor grow?
>>>>>> I would love to specify the order by myself not by the arbitrary 
>>>>>> order
>>>>>> generated by the compiler.
>>>>>>
>>>>
>>>> Hi,
>>>>
>>>> Can someone explain me what is exactly the problems with static 
>>>> this? Something like a small example that shows the problem, so I 
>>>> can at least think of a solution (because I don't know the problem).
>>>>
>>>> Thanks!
>>>> Ary
>>>   Something like:
>>>  file1.d:
>>>  import file2.d;
>>>  static this()
>>> {
>>> }
>>>  file2.d:
>>>  import file1.d;
>>>  static this()
>>> {
>>> }
>>>  fails to compile due to the perceived circular dependency, even 
>>> though none exists.
>>
>> Thanks, yes, it fails to run. But why? What could happen if that error 
>> wasn't issued? I'm looking for an example where something wrong could 
>> happen.
> 
> I gave you the case which *should* compile, here is a case Walter is 
> trying to prevent:
> 
> file1.d:
> import file2;
> 
> int x;
> static this()
> {
>   x = y;
> }
> 
> file2.d:
> 
> int y;
> static this()
> {
>   y = x;
> }
> 
> This is an obvious case, it doesn't take much imagination to envision 
> one that's not so obvious.

I'm starting to understand the problem. In this example I think I can 
describe better the real problem:

file1.d:
import file2;

int x;
static this() {
   x = y + 10;
}

file2:d
int y;
static this() {
   y = 20;
}

In this case the programmer expects y to be 20, and x to be 30 (since 
file1 references file2, it expects to run the static this of file2 
first). And this one compiles fine because file2 doesn't import file1.

As soon as file2 imports file1, you get the error, *even though no 
symbol of file1 that is referenced in a file1's static this has been 
referenced in file2's static this*.

Isn't this the real problem? For this solution the compiler should 
maintain references to modules only if they are referenced in the static 
if's, so for this example it would be:

file1 -> { file2 }
file2 -> {}

so there's no circularity. For your example it would be:

file1 -> { file2 }
file2 -> { file1 }

and there's a circularity, and you get a *compile* error (I think this 
will always be a real error).

Of course this gets complicated if the static this invokes functions, 
maybe it creates instances of classes, cast them to interfaces or to 
base classes, and then invoke some method and now you can't tell which 
variables are referenced. But I can't truly imagine a case where this 
will be a problem. And if it is, then there's something wrong in your 
initialization logic, that is, a bug, and you should fix it. But most of 
the time, I think, there won't be problems.

Is there something wrong in my reasoning?