allMembers broke for __

[DigitalDesigns]

On Monday, 18 June 2018 at 21:47:01 UTC, Steven Schveighoffer 
wrote:
> On 6/18/18 5:27 PM, Walter Bright wrote:
>> On 6/18/2018 3:54 AM, Timon Gehr wrote:
>>> The code you linked to does it. :)
>> 
>> I know. But it shouldn't. Do as I say, not as I do :-)
>
> I don't see how you misuse the symbols.
>
> I think it's more that you shouldn't *define* these symbols, 
> not that you can't use the language-defined symbols in the 
> intended way.
>
> The complaint here is that they are treated differently from 
> normal symbols. The answer is, they are special, so don't 
> assume they aren't.
>
> -Steve

The complaint is not that, the complaint is that when one does 
use these symbols, which they are allowed to use because the 
compiler permits it, then __traits hides those symbols instead of 
returning them.


This means if one uses such a symbol name then template code can 
silently fail to work as intended and there is no way to 
determine the problem except know that the leading __ is causing 
it. This type of behavior would rarely be suspect causing the 
programmer to waste many hours trying to figure out the problem. 
In some cases the bug may never be solved and occur rarely and in 
production.

The compiler/traits is treating identifiers that begin with __ 
differently than those that done but they should be treated 
uniformly the same since technically __ in front of an identifier 
does not change anything.

struct X
{
int __a = 0;
int a = 0;
}

are totally different with respect to allMembers when few would 
expect it to be so except.

What I'm saying is that if you guys don't want users to use __ 
then make it an error! That simple. You can allow it in internal 
code and phobos but restrict it in user code, it's really that 
simple... or fix traits to return those values. It would be 
better to let the users check if they want to process them or not 
instead of doing it internally and potential breaking code.