static this sucks, we should deprecate it

[grauzone]

Walter Bright wrote:
> Jarrett Billingsley wrote:
>> On Sun, May 31, 2009 at 4:39 PM, Walter Bright
>> <newshound1 at digitalmars.com> wrote:
>>> The solution is relatively robust and straightforward. Create a third
>>> module, AB. Module A and module B both import AB. Put the static
>>> constructors for both A and B in module AB. The order of initialization
>>> problem is robustly solved, and all the interdependencies of 
>>> initialization
>>> of A and B are explicitly laid out in AB.
>>
>> If I might speak from personal experience, what usually ends up
>> happening instead is that A and B get merged into a single module.
>> This happens enough times, and you have half your code in one file.
> 
> What is wrong with the approach I outlined? I use it, it works fine.

1. Requires more code
2. Requires additional modules (!)
(as a consequence to 1+2, code is a lot less clearer to read)
3. When you want template mixins to contain a static this, your approach 
doesn't really work at all. The template mixin obviously can't generate 
a new module to move the static ctor there. As an example for real life 
usage, look at BCS's serialization code. (See his thread on 
d.D.announce, code link is on his blog post.) He uses a template mixin 
containing a static ctor, to make a class "known" to the serialization 
system. Using a template mixin with static ctor is a nice way to hide 
that mechanism from the user, but it disallows cyclic module 
dependencies. I claim that many users, who try to substitute the lacking 
RTTI with a custom mechanism, will hit the same problem.