Trait keyword.

[Maxim Fomin]

On Saturday, 2 November 2013 at 21:28:46 UTC, Adam D. Ruppe wrote:
> On Saturday, 2 November 2013 at 20:45:28 UTC, TheFlyingFiddle 
> wrote:
>> I'm basically wondering why the __traits keyword looks so 
>> horrible.
>
> I think it looks beautiful and wished all the keywords used the 
> leading underscores.

This is about taste and it is subjective.

> The reason is that the __keywords are reserved, so they don't 
> conflict with user words. __traits was added somewhat late into 
> the language, so using a reserved word for it meant less broken 
> code. Now you can still call your own variables traits - I'd 
> love it if all keywords were this way so we could, in theory at 
> least, use the anywhere.

Statement that in D __identifiers are reserved is dubious as 
nothing stops users from defining them (I was under impression 
that D really prevents but is actually was misconception). D 
incorporates substantial amount of C but does not impose similar 
limitations on reserved identifiers (__identifier is not the only 
one reserved in C). Futhermore, dmd internally generates lots of 
identifiers and does not prohibit user from 'picking up' them - 
it is huge amount of accept-invalid code. There is also a bug 
that code

struct S { void __foo(){} void bar() {} }
pragma(msg, __traits(allMembers, S));

printed only 'bar' since some commit in 2.064 (I haven't tested 
current version). Except these issues, '__identifiers' and 
'identifiers' are pretty much the same. Using the former bears 
some 'risk' that such identifiers may hijack some symbol but it 
is low.

I believe that __trais was chosen because of combination of 
unwillingness to intervene into 'identifiers' category (in some 
sense it is desire to 'stabilize the language' by pretending that 
language is 'stable') and belief that introducing new 
features/fixing existing features should not break existing code 
(but it is inconsistent policy as the same time pretty much code 
is broken each release, and there is pretty much another code 
which will very likely be broken in the future). Anyway, the 
decision seems to be within the path which was followed by C 
(_Noreturn, _Thread_local), so it is not that bad.