CTFE & enums & static assert

[Ali Çehreli via Digitalmars-d-learn]

On 05/04/2015 11:07 AM, Robert M. Münch wrote:

 > enum A {a, b, c};
 >
 > enum members1 = __traits(allMembers, A);
 > auto members2 = __traits(allMembers, A);
 >

 > 1. So the (string, string, string) output is based on the expression of
 > members1? Meaning, the right-hand-side.

There are many different kinds of tuples in D, only two of which I can 
handle:

1) Tuple from std.typecons, which are ordinarily created at run time

2) TypeTuple from std.typetuple, which are compile-time entities

The documentation is not clear that __traits(allMembers) returns a 
TypeTuple, which additionally has a bad name.

TypeTuple is great because it enables "compile-time foreach" 
(unfortunately, implicitly):

     foreach (m; __traits(allMembers, A)) {
         // This body is repeated for each member at compile time
     }

It is also possible to expand members of a TypeTuple just by putting it 
inside an array:

   [ __traits(allMembers, A) ]On 05/04/2015 11:07 AM, Robert M. Münch wrote:

 > enum A {a, b, c};
 >
 > enum members1 = __traits(allMembers, A);
 > auto members2 = __traits(allMembers, A);
 >

 > 1. So the (string, string, string) output is based on the expression of
 > members1? Meaning, the right-hand-side.

There are many differents kinds of tuples in D, only two of which I can 
handle:

1) Tuple from std.typecons, which are ordinarily created at run time

2) TypeTuple from std.typetuple, which are compile-time entities

The documentation is not clear that __traits(allMembers) returns a 
TypeTuple, which additionally has a bad name.

TypeTuple is great because it enables "compile-time foreach" 
(unfortunately, implicitly):

     foreach (m; __traits(allMembers, A)) {
         // This body is repeated for each member at compile time
     }

It is also possible to expand members of a TypeTuple just by putting it 
inside an array:

   [ __traits(allMembers, A) ]

However, it should be obvious that all members must have a common type 
to be members of the same array. (True to its name, TypeTuple can have 
types themselves as well.)

Powerful stuff. :)

 > 2. I'm wondering why members1 doesn't has a type at all.

Because it is a TypeTuple of values of various types and even types 
themselves.

 > So, we don't
 > have a compile-time boolean?

I don't understand that one. :(

Ali


However, it should be obvious that all members must have a common type 
to be members of the same array. (True to its name, TypeTuple can have 
types themselves as well.)

Powerful stuff. :)

 > 2. I'm wondering why members1 doesn't has a type at all.

Because it is a TypeTuple of values of various types and even types 
themselves.

 > So, we don't
 > have a compile-time boolean?

I don't understand that one. :(

Ali