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

Reply via email to