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.
