allMembers broke for __

Steven Schveighoffer schveiguy at yahoo.com
Tue Jun 19 12:59:00 UTC 2018


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


More information about the Digitalmars-d mailing list