www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Lazy evaluation of enum members

reply Walter Bright <newshound2 digitalmars.com> writes:
Enum member forward references now work:

void main()
{
     enum E
     {
         A = B,
         E = D + 7,
         B = 3,
         C,
         D,
     }

     assert(E.A == 3);
     assert(E.B == 3);
     assert(E.C == 4);
     assert(E.D == 5);
     assert(E.E == 12);
     assert(E.max == 12);
}

https://github.com/D-Programming-Language/dmd/pull/2568

Once this is pulled, I intend to extend it so that enum members for imports are 
not semantically evaluated at all unless they are used. This is a first step to 
making all semantic evaluation of imports lazy, which should give us a big
boost 
in compilation speed, as well as do a much better job at handling forward 
references.

I've been meaning to do this for some time, starting with enums because they
are 
the easiest.
Sep 20 2013
next sibling parent "Gary Willoughby" <dev nomad.so> writes:
On Friday, 20 September 2013 at 16:10:11 UTC, Walter Bright wrote:
 Enum member forward references now work:

 void main()
 {
     enum E
     {
         A = B,
         E = D + 7,
         B = 3,
         C,
         D,
     }

     assert(E.A == 3);
     assert(E.B == 3);
     assert(E.C == 4);
     assert(E.D == 5);
     assert(E.E == 12);
     assert(E.max == 12);
 }

 https://github.com/D-Programming-Language/dmd/pull/2568

 Once this is pulled, I intend to extend it so that enum members 
 for imports are not semantically evaluated at all unless they 
 are used. This is a first step to making all semantic 
 evaluation of imports lazy, which should give us a big boost in 
 compilation speed, as well as do a much better job at handling 
 forward references.

 I've been meaning to do this for some time, starting with enums 
 because they are the easiest.

Awesome!
Sep 20 2013
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, September 20, 2013 09:10:10 Walter Bright wrote:
 Enum member forward references now work:
 
 void main()
 {
      enum E
      {
          A = B,
          E = D + 7,
          B = 3,
          C,
          D,
      }
 
      assert(E.A == 3);
      assert(E.B == 3);
      assert(E.C == 4);
      assert(E.D == 5);
      assert(E.E == 12);
      assert(E.max == 12);
 }
 
 https://github.com/D-Programming-Language/dmd/pull/2568
 
 Once this is pulled, I intend to extend it so that enum members for imports
 are not semantically evaluated at all unless they are used. This is a first
 step to making all semantic evaluation of imports lazy, which should give
 us a big boost in compilation speed, as well as do a much better job at
 handling forward references.
 
 I've been meaning to do this for some time, starting with enums because they
 are the easiest.

But if you make the compiler too fast, then this XKCD won't be true anymore! ;) http://xkcd.com/303/ - Jonathan M Davis
Sep 20 2013
prev sibling next sibling parent reply Manfred Nowak <svv1999 hotmail.com> writes:
Walter Bright wrote:

 Enum member forward references now work:

Replace `D,' by `D = E + 1'? And still: shouldn't `enum's be weakly ordered? -manfred
Sep 20 2013
parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/20/2013 11:10 AM, Manfred Nowak wrote:
 Walter Bright wrote:

 Enum member forward references now work:

Replace `D,' by `D = E + 1'?

That is a circular reference, not a forward one, and is an error.
 And still: shouldn't `enum's be weakly ordered?

??
Sep 20 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Sep 20, 2013 at 11:06:29AM -0700, Jonathan M Davis wrote:
[...]
 But if you make the compiler too fast, then this XKCD won't be true
 anymore!  ;)
 
 http://xkcd.com/303/

It's a surprisingly effective excuse. :-P T -- All problems are easy in retrospect.
Sep 20 2013
prev sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 9/20/13, Walter Bright <newshound2 digitalmars.com> wrote:
 Enum member forward references now work.

Could you please look at the following report and then close it as invalid if the change was intended? http://d.puremagic.com/issues/show_bug.cgi?id=11130 If it's invalid we could add some documentation for how to work around the (relatively rare) issue.
Sep 27 2013