On Sunday, 17 June 2018 at 22:55:57 UTC, Walter Bright wrote:
> On 6/15/2018 11:08 PM, DigitalDesigns wrote:
>> When an identifier starts with __, allMembers does not return it. This is very bad behavior! It can silently create huge problems if the programmer is not aware of the bug.
>
>
> It's not a bug, it's quite deliberate:
>
>   https://github.com/dlang/dmd/blob/master/src/dmd/traits.d#L1385
>
>
> Identifiers starting with __ are reserved for the implementation:
>
>   https://dlang.org/spec/lex.html#identifiers
>
> They have implementation-defined behavior. Do not use them in user code.

If you don't want me to use it then why not give an error instead of punishing me by introducing very difficult bugs to detect?

Do you really think that everyone that starts using D will automatically know the traps of __ and avoid it like the plague just because you said so(even though they probably never actually seen you say it)?

How about instead of __, you guys use ____ in your code? That would be more sane than breaking my code because I used an extra _.

Again, you can justify all you want... it doesn't make it right.

On Sun, 2018-06-17 at 15:55 -0700, Walter Bright via Digitalmars-d wrote:
> 
[…]
> Identifiers starting with __ are reserved for the implementation:
> 
>    https://dlang.org/spec/lex.html#identifiers
> 
> They have implementation-defined behavior. Do not use them in user code.

In delegates I have found I have to use _ and __ (and ___, ____, etc.,but I have only had to use two to date) for delegate parameters that are to be unused and unnamed. Are these treated differently because they are all underscores?

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

On 18.06.2018 00:55, Walter Bright wrote:
> On 6/15/2018 11:08 PM, DigitalDesigns wrote:
>> When an identifier starts with __, allMembers does not return it. This is very bad behavior! It can silently create huge problems if the programmer is not aware of the bug.
> 
> 
> It's not a bug, it's quite deliberate:
> 
>    https://github.com/dlang/dmd/blob/master/src/dmd/traits.d#L1385
> 
> 
> Identifiers starting with __ are reserved for the implementation:
> 
>    https://dlang.org/spec/lex.html#identifiers
> 
> They have implementation-defined behavior. Do not use them in user code.

The code you linked to does it. :)

On Monday, 18 June 2018 at 08:25:46 UTC, Russel Winder wrote:
> On Sun, 2018-06-17 at 15:55 -0700, Walter Bright via Digitalmars-d wrote:
>> 
> […]
>> Identifiers starting with __ are reserved for the implementation:
>> 
>>    https://dlang.org/spec/lex.html#identifiers
>> 
>> They have implementation-defined behavior. Do not use them in user code.
>
> In delegates I have found I have to use _ and __ (and ___, ____, etc.,but I have only had to use two to date) for delegate parameters that are to be unused and unnamed. Are these treated differently because they are all underscores?

Well you can use identifiers that uses __, but certain names that uses __ as a prefix will have implementation defined behavior.

I guess for parameters that are strictly __ etc. they're just behaving "normal" because there are no implementation behavior for said identifiers and thus defaults to "normal behavior".

I also guess it's mostly an issue with function names, field names etc. and not really paramters, but I could be wrong.

On 6/18/18 12:57 PM, bauss wrote:
> On Monday, 18 June 2018 at 08:25:46 UTC, Russel Winder wrote:
>> On Sun, 2018-06-17 at 15:55 -0700, Walter Bright via Digitalmars-d wrote:
>>>
>> […]
>>> Identifiers starting with __ are reserved for the implementation:
>>>
>>>    https://dlang.org/spec/lex.html#identifiers
>>>
>>> They have implementation-defined behavior. Do not use them in user code.
>>
>> In delegates I have found I have to use _ and __ (and ___, ____, etc.,but I have only had to use two to date) for delegate parameters that are to be unused and unnamed. Are these treated differently because they are all underscores?

You can just not give them names.

> Well you can use identifiers that uses __, but certain names that uses __ as a prefix will have implementation defined behavior.
> 
> I guess for parameters that are strictly __ etc. they're just behaving "normal" because there are no implementation behavior for said identifiers and thus defaults to "normal behavior".
> 
> I also guess it's mostly an issue with function names, field names etc. and not really paramters, but I could be wrong.

For names that won't be used, it doesn't matter what the name is. In some languages, the single underscore symbol is reserved for names that won't be used. So when porting to D, perhaps there is the case where you might feel they need other non-standard names.

However, in this case, D does not require names, so it's a moot point.

-Steve

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 :-)

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

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.

On Sunday, 17 June 2018 at 22:55:57 UTC, Walter Bright wrote:
> On 6/15/2018 11:08 PM, DigitalDesigns wrote:
>> When an identifier starts with __, allMembers does not return it. This is very bad behavior! It can silently create huge problems if the programmer is not aware of the bug.
>
>
> It's not a bug, it's quite deliberate:
>
>   https://github.com/dlang/dmd/blob/master/src/dmd/traits.d#L1385
>
>
> Identifiers starting with __ are reserved for the implementation:
>
>   https://dlang.org/spec/lex.html#identifiers
>
> They have implementation-defined behavior. Do not use them in user code.

Holy cyclomatic complexity batman!

Is the extern(C++) on semanticTraits remnants from converting dmd to d?

Cheers
- Ali

On 6/18/2018 11:42 PM, aliak wrote:
> Is the extern(C++) on semanticTraits remnants from converting dmd to d?

No, it's to be callable from the 3 non-D back ends.