I have made a small test to investigate the additional enum features coming with DMD 2.009.

I'm using dmd to compile this test program:

import std.stdio;

// anonymous enum
enum
{
  ival = 1304,
  dval = 1965.0,
  chr1 = 'a',
  chrm = "This is a anonymous enum member string."
}

// manifest constants
enum ival_ = 1304;
enum dval_ = 1965.0;
enum chr1_ = 'b';
enum chrm_ = "This is a manifest constant string.";


void main()
{
  writefln("Test anonymous enum members.");
  writefln("----------------------------");
  writefln("ival = ", ival);
  writefln("dval = ", dval);
  writefln("chr1 = ", chr1);
  writefln("chrm = ", chrm, "\n");

  writefln("Test manifest constants.");
  writefln("------------------------");
  writefln("ival_ = ", ival_);
  writefln("dval_ = ", dval_);
  writefln("chr1_ = ", chr1_);
  writefln("chrm_ = ", chrm_, "\n");

}

and got these results:

Test anonymous enum members.
----------------------------
ival = 1304
dval = 1965
chr1 = a
chrm = This is a anonymous enum member string.

Test manifest constants.
------------------------
ival_ = 1304
dval_ = 1965
chr1_ = b
chrm_ = ¸B 
       €ÿ Ä… ´3B H­@ 1   ´3B


The last line of output looks wrong, but using a string as an anonymous enum member gives the desired result.

Is there a difference between an anonymous enum member and a manifest constant considering a string?

Regards

Sivo Schilling wrote:
> 
> Is there a difference between an anonymous enum member and a manifest
> constant considering a string?

I wouldn't expect so.  In fact I wonder if it shouldn't be a compile error to pass a manifest constant string to a run-time function.  How can you take the address of something with no storage?


Sean

Sivo Schilling wrote:
> Is there a difference between an anonymous enum member and a manifest
> constant considering a string?

I tried it with an int array, seems that's broken too.  I'm hoping for a bugfix release soon, so we can try out the features properly. :)

---
import std.stdio;

enum int[] array = [1, 2, 3];

void main()
{
   writefln(array); // ok, prints [1, 2, 3]

   foreach (x; array)  // access violation with 2.009
      writefln(x);
}
---

torhu Wrote:

> Sivo Schilling wrote:
> > Is there a difference between an anonymous enum member and a manifest constant considering a string?
> 
> I tried it with an int array, seems that's broken too.  I'm hoping for a bugfix release soon, so we can try out the features properly. :)
> 
> ---
> import std.stdio;
> 
> enum int[] array = [1, 2, 3];
> 
> void main()
> {
>     writefln(array); // ok, prints [1, 2, 3]
> 
>     foreach (x; array)  // access violation with 2.009
>        writefln(x);
> }
> ---

I´ve got the same results with your code. But with a small modification your code works without any error messages:

---
import std.stdio;

enum {int[] array = [1, 2, 3]}

void main()
{
    writefln(array); // ok, prints [1, 2, 3]

    foreach (x; array)
       writefln(x);
    // ok, prints
    // 1
    // 2
    // 3
}
---

So, I believe the reason could be bracketing or no bracketing? But trying the latter case is it a bug ?

Regards

Sean Kelly Wrote:

> Sivo Schilling wrote:
> > 
> > Is there a difference between an anonymous enum member and a manifest constant considering a string?
> 
> I wouldn't expect so.  In fact I wonder if it shouldn't be a compile error to pass a manifest constant string to a run-time function.  How can you take the address of something with no storage?
> 
> 
> Sean

Why should it a compile time error ? From the specs I guess
that the enhanced enum feature acts as "#define" in C/C++.
And it works as shown in my simple code example.
The question is bracketing or no bracketing!

With this small modification of the original code

// enum chrm_ = "This is a manifest constant string.";
enum { chrm_ = "This is a manifest constant string."}

the result is as expected.

In this light the specs considering manifest constants should be verified for arrays of any kind.

Sivo

Sivo Schilling wrote:
> Sean Kelly Wrote:
> 
>> Sivo Schilling wrote:
>>> Is there a difference between an anonymous enum member and a manifest
>>> constant considering a string?
>> I wouldn't expect so.  In fact I wonder if it shouldn't be a compile error to pass a manifest constant string to a run-time function.  How can you take the address of something with no storage?
> 
> Why should it a compile time error ? From the specs I guess
> that the enhanced enum feature acts as "#define" in C/C++.

Oh good point.  So storage is provided for manifest string constants which are actually used in the program, just like string literals.  That makes sense.  But I do still consider the brackets vs. no brackets issue to be a bug.  Both should print the string successfully then.


Sean

Looks like a compiler bug to me.

Sean Kelly wrote:
> Sivo Schilling wrote:
>> Sean Kelly Wrote:
>>
>>> Sivo Schilling wrote:
>>>> Is there a difference between an anonymous enum member and a manifest
>>>> constant considering a string?
>>> I wouldn't expect so.  In fact I wonder if it shouldn't be a compile error to pass a manifest constant string to a run-time function.  How can you take the address of something with no storage?
>>
>> Why should it a compile time error ? From the specs I guess
>> that the enhanced enum feature acts as "#define" in C/C++.
> 
> Oh good point.  So storage is provided for manifest string constants which are actually used in the program, just like string literals.  That makes sense.  But I do still consider the brackets vs. no brackets issue to be a bug.  Both should print the string successfully then.
> 
> 
> Sean

I hope this isn't intentional behavior... if so, it's WAY too confusing, and should be changed.