On 6/19/18 2:23 AM, DigitalDesigns wrote:
> 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.
>>
> 
> 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 is pretty similar to what I said, but I misunderstood that your beef is not with the fact that __symbols are special, but that the compiler let's mere mortals use them. Which is a good point.

> 
> 
> 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.

There are a few things in D like this, for example operator overloads. They are normal functions but add compiler recognition for some things.

One of the things I'm concerned about with this is that people may (ab)use this knowledge to add "hidden" pieces to structs on purpose.

> 
> 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.

This is a pretty reasonable request, and it makes sense. It could be done pretty simply -- if a type is defined with __someSymbol and it's not in std, core, or rt, give an error. If we are reserving these symbols for the language, there's no reason to not enforce that requirement.

I'd recommend putting in an enhancement request in bugzilla.

-Steve

On Tuesday, 19 June 2018 at 12:59:00 UTC, Steven Schveighoffer wrote:
> I'd recommend putting in an enhancement request in bugzilla.

Done:
https://issues.dlang.org/show_bug.cgi?id=19028

Really, this behaviour at least should be reflected in `allMembers` and `derivedMembers` documentation.