View mode: basic / threaded / horizontal-split · Log in · Help
December 01, 2012
Re: Fixing cyclic import static construction problems
On Saturday, 1 December 2012 at 12:08:10 UTC, Artur Skawina wrote:
> The key words are "known" and "initialized". IOW
>
>    const int a = 42;
>
> doesn't add a dep, but
>
>   const int a;
>
> does.
>
> /Modifying/ initialized const data from a mod ctor is (and 
> should be) illegal.
>

That make sense.

> D's pure isn't enough, because it will allow accesses to 
> external immutable
> data - which can be modified by a mod ctor. But like i said - 
> this might not be
> a problem in practice, as it's just about the cross-module 
> non-ctfeable, but
> truly pure function calls inside mod ctors - is this really 
> something that occurs
> often enough?
>

Ho yes, this make sense too. CTFEable is still too restrictive 
but pure isn't enough.

> I'm not sure what assertion you think is false, but 
> theoretically it /is/ possible
> to figure out the deps at runtime, even w/o any hints. Think 
> valgrind. But it's
> a very bad idea, with a significant runtime cost (not as bad as 
> valgrind since you
> can figure out some things statically, but determining the 
> order alone would already
> be too slow for larger projects with many symbols and deps.)
>

The assertion is that it must be done at runtime. It is obviously 
doable at runtime, but complicated. I think that most of it can 
be done at compile time.
December 02, 2012
Re: Fixing cyclic import static construction problems
On Thursday, 29 November 2012 at 02:34:11 UTC, Walter Bright 
wrote:
> For discussion:
>
> Cyclical Imports
>
> Problem:
>
> ---- a.d ----
>     module a;
>     import b;
>     static this () { ... }
> ---- b.d ----
>     module b;
>     import a;
>     static this() { ... }
> -------------
>
> Static constructors for a module are only run after static 
> constructors
> for all its imports are run. Circular imports, such as the 
> above, are
> detected at run time and the program is aborted.
>
> This can in general be solved by moving the static 
> constructor(s) into
> a third module, c.d, which does not import a or b. But, people 
> find this
> to be unnatural.
>
> Proposed Solution:
>
> Add a pragma,
>
>     pragma(cyclic_imports);
>
> This can appear anywhere in a module, and applies globally to 
> that module.
> It means that static constructors from imports that are not 
> part of the cycle
> are run first, and that the static constructor for this module 
> may be run before
> the static constructors of other modules that are part of the 
> cycle.
>
> If any static constructors in such a module with the pragma have
> the @safe attribute, that is a compile time error.

While more complex, would it be possible to declare which 
imported modules can be constructed after the current one? That 
allows catching any other unintended cyclic imports. For example:

static this {
  pragma(cyclic_import, b);
  // code that does not depend on
  // static constructor(s) in module b
}
December 02, 2012
Re: Fixing cyclic import static construction problems
Jonathan M Davis wrote:

> Or do you mean something else by the suggestion that the
> existence of Walter's pragma can be assumed?

In

http://forum.dlang.org/thread/k96hj2$2lus$1@digitalmars.com?
page=4#post-k98o7j:24qb6:241:40digitalmars.com

Walter pointed this out for a clique of imports. All but one 
members of a clique are to have that pragma anyway---and Walter 
claims, that there is no error introduced, when the remaining 
member has that pragma too.

-manfred
December 07, 2012
Re: Fixing cyclic import static construction problems
On Thu, 29 Nov 2012 12:39:19 +0100
"Paulo Pinto" <pjmlp@progtools.org> wrote:

> On Thursday, 29 November 2012 at 03:19:55 UTC, Andrei 
> Alexandrescu wrote:
> > On 11/28/12 9:34 PM, Walter Bright wrote:
> >> For discussion:
> > [snip]
> >
> > I'd say we better finish const, immutable, and shared first.
> >
> > Andrei
> 
> +1
> 
> Fully agree.
> 
> Cyclic imports are a minor nuisance that can be easily solvable 
> with better code architecture.
> 

Or just lazy initialization:

   Foo f = blah();

-->

   private Foo _f;
   private bool fInited=false;
   @property Foo f()
   {
       if(!fInited)
       {
           _f = blah();
           fInited = true;
       }

       return _f;
   }

And that boilerplate's trivially wrapped up with a mixin.
Next ›   Last »
3 4 5 6 7
Top | Discussion index | About this forum | D home