My thoughts & experiences with D so far, as a novice D coder

H. S. Teoh hsteoh at quickfur.ath.cx
Wed Mar 27 11:06:54 PDT 2013


On Wed, Mar 27, 2013 at 01:59:13PM -0400, Nick Sabalausky wrote:
> On Wed, 27 Mar 2013 10:05:08 -0700
> "H. S. Teoh" <hsteoh at quickfur.ath.cx> wrote:
> 
> > On Wed, Mar 27, 2013 at 04:34:19PM +0100, Vidar Wahlberg wrote:
> > [...]
> > 
> > > - "Foo foo = new Foo();" for global variables/class members. Now you
> > > must "Foo foo; static this() { foo = new Foo(); }".
> > 
> > Yeah, this is an irksome limitation. Though, it does have the
> > benefit of not letting you do something that incurs runtime-cost
> > without being explicit about it. Still, it is cumbersome to have to
> > use static this() all over the place. It would be nice for the
> > compiler to automatically lower such things into implicit ctor
> > calls.
> > 
> 
> I wouldn't want such things to be implicitly converted to static ctors
> unless the cyclic dependency issue was somehow ironed out.

True.


> I don't mind initializers of mutable vars being implicitly run at
> runtime (that convenience would certainly be nice), but I definitely
> don't want "cyclic dependency error" being triggered by something so
> innocent-looking.

I wonder if it would solve the problem if different instances of static
ctors in the same module are regarded as separate entities with their
own dependencies, so that you won't get a cyclic dependency error unless
there's truly an irreducible cyclic dependency. That is, cyclic
dependency errors shouldn't happen just because *one* static ctor
depends on stuff that indirectly depends on one of the 20 other static
ctors.

Don't know if this will cause conflicts with the current way module
dependencies work, though.


T

-- 
Кто везде - тот нигде.


More information about the Digitalmars-d mailing list