Is this a bug with __traits(derivedMembers)?

[Basile B.]

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.