www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Is this a bug with __traits(derivedMembers)?

reply bauss <jj_1337 live.dk> writes:
See the following: https://run.dlang.io/is/uQ21PH

(I have tried with allMembers too.)

It's like it won't pick up the member that is added using a mixin 
at line 22.

```
mixin("ubyte[" ~ to!string(__PADDING_SIZE__) ~ "] __PADDING__" ~ 
member  ~ ";");
```

As you can see if you take sizeof from the struct then it gets 
the correct size, so it's like the member exists, but you cannot 
retrieve it with traits.

It's possible to retrieve it manually, so yeah...

If it's a bug then I will file an issue unless someone else will 
do so.

If it's not a bug, then what's going on and what would the 
correct solution be?
Jun 12 2018
next sibling parent bauss <jj_1337 live.dk> writes:
On Tuesday, 12 June 2018 at 13:40:45 UTC, bauss wrote:

 See the following: https://run.dlang.io/is/uQ21PH


Note: Look at the comments in the code.
Jun 12 2018
prev sibling parent reply ag0aep6g <anonymous example.com> writes:
On Tuesday, 12 June 2018 at 13:40:45 UTC, bauss wrote:

 See the following: https://run.dlang.io/is/uQ21PH

 (I have tried with allMembers too.)

 It's like it won't pick up the member that is added using a 
 mixin at line 22.

 ```
 mixin("ubyte[" ~ to!string(__PADDING_SIZE__) ~ "] __PADDING__" 
 ~ member  ~ ";");
 ```


It's because the identifier starts with two underscores. Such 
identifiers are reserved for internal use, and apparently they're 
ignored by some (all?) __traits.

I'm not sure if this can count as a bug, but it doesn't look just 
fine either.

Smaller test case:

----
struct S
{
     int foo, __bar, baz;
}
pragma(msg, __traits(allMembers, S)); /* tuple("foo", "baz") */
----
Jun 12 2018
parent reply Bauss <jj_1337 live.dk> writes:
On Tuesday, 12 June 2018 at 14:37:19 UTC, ag0aep6g wrote:

 On Tuesday, 12 June 2018 at 13:40:45 UTC, bauss wrote:

 See the following: https://run.dlang.io/is/uQ21PH

 (I have tried with allMembers too.)

 It's like it won't pick up the member that is added using a 
 mixin at line 22.

 ```
 mixin("ubyte[" ~ to!string(__PADDING_SIZE__) ~ "] __PADDING__" 
 ~ member  ~ ";");
 ```


 It's because the identifier starts with two underscores. Such 
 identifiers are reserved for internal use, and apparently 
 they're ignored by some (all?) __traits.

 I'm not sure if this can count as a bug, but it doesn't look 
 just fine either.

 Smaller test case:

 ----
 struct S
 {
     int foo, __bar, baz;
 }
 pragma(msg, __traits(allMembers, S)); /* tuple("foo", "baz") */
 ----


Thank you. I was not aware of such a gotcha.

Should definitely be documented or yield an error/warning if 
attempted in user code else you end up with hidden "bugs" like 
this
Jun 12 2018
parent reply Basile B. <b2.b2.b2.temp.temp.temp gmx.gmx.com> writes:
On Tuesday, 12 June 2018 at 15:42:50 UTC, Bauss wrote:

 On Tuesday, 12 June 2018 at 14:37:19 UTC, ag0aep6g wrote:

 On Tuesday, 12 June 2018 at 13:40:45 UTC, bauss wrote:

 See the following: https://run.dlang.io/is/uQ21PH

 (I have tried with allMembers too.)

 It's like it won't pick up the member that is added using a 
 mixin at line 22.

 ```
 mixin("ubyte[" ~ to!string(__PADDING_SIZE__) ~ "] 
 __PADDING__" ~ member  ~ ";");
 ```


 It's because the identifier starts with two underscores. Such 
 identifiers are reserved for internal use, and apparently 
 they're ignored by some (all?) __traits.

 I'm not sure if this can count as a bug, but it doesn't look 
 just fine either.

 Smaller test case:

 ----
 struct S
 {
     int foo, __bar, baz;
 }
 pragma(msg, __traits(allMembers, S)); /* tuple("foo", "baz") */
 ----


 Thank you. I was not aware of such a gotcha.

 Should definitely be documented or yield an error/warning if 
 attempted in user code else you end up with hidden "bugs" like 
 this


Identifier starting with 2 underscores are documented as reserved 
[1]. I think that we can take this as a clear warning (reached 
this too once with an enum member that i tried to convert to 
string...)

[1]: https://dlang.org/spec/lex.html#identifiers

I don't know if more doc is necessary. The warning is at its 
right place IMO.
Jun 12 2018
parent reply bauss <jj_1337 live.dk> writes:
On Tuesday, 12 June 2018 at 17:24:31 UTC, Basile B. wrote:

 On Tuesday, 12 June 2018 at 15:42:50 UTC, Bauss wrote:

 On Tuesday, 12 June 2018 at 14:37:19 UTC, ag0aep6g wrote:

 On Tuesday, 12 June 2018 at 13:40:45 UTC, bauss wrote:

 See the following: https://run.dlang.io/is/uQ21PH

 (I have tried with allMembers too.)

 It's like it won't pick up the member that is added using a 
 mixin at line 22.

 ```
 mixin("ubyte[" ~ to!string(__PADDING_SIZE__) ~ "] 
 __PADDING__" ~ member  ~ ";");
 ```


 It's because the identifier starts with two underscores. Such 
 identifiers are reserved for internal use, and apparently 
 they're ignored by some (all?) __traits.

 I'm not sure if this can count as a bug, but it doesn't look 
 just fine either.

 Smaller test case:

 ----
 struct S
 {
     int foo, __bar, baz;
 }
 pragma(msg, __traits(allMembers, S)); /* tuple("foo", "baz") 
 */
 ----


 Thank you. I was not aware of such a gotcha.

 Should definitely be documented or yield an error/warning if 
 attempted in user code else you end up with hidden "bugs" like 
 this


 Identifier starting with 2 underscores are documented as 
 reserved [1]. I think that we can take this as a clear warning 
 (reached this too once with an enum member that i tried to 
 convert to string...)

 [1]: https://dlang.org/spec/lex.html#identifiers

 I don't know if more doc is necessary. The warning is at its 
 right place IMO.


If they're reserved the compiler should honestly throw a warning 
at the very least.

People should have to read through the docs for warnings.
Jun 12 2018
parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 6/12/18 4:19 PM, bauss wrote:

 On Tuesday, 12 June 2018 at 17:24:31 UTC, Basile B. wrote:

 I don't know if more doc is necessary. The warning is at its right 
 place IMO.


 
 If they're reserved the compiler should honestly throw a warning at the 
 very least.
 
 People should have to read through the docs for warnings.


They are reserved by the language, not necessarily by the compiler. In 
other words, druntime could potentially define double-underscore items 
without violating the spec. Having to require a compiler change for such 
things may be too much.

I didn't know that __traits would ignore them, though, that's pretty 
interesting.

-Steve
Jun 12 2018