static this sucks, we should deprecate it

Steven Schveighoffer schveiguy at yahoo.com
Thu May 28 09:29:57 PDT 2009


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.

-Steve



More information about the Digitalmars-d mailing list