www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Trait keyword.

reply "TheFlyingFiddle" <theflyingfiddle gmail.com> writes:
I'm basically wondering why the __traits keyword looks so 
horrible.
Nov 02 2013
next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
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.

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.

Anyway, std.traits wraps __traits reasonably well and doesn't 
have the underscores.
Nov 02 2013
next sibling parent "TheFlyingFiddle" <theflyingfiddle gmail.com> writes:
Thanks for the comprehensive answer.
Nov 02 2013
prev sibling next sibling parent reply "Namespace" <rswhite4 googlemail.com> writes:
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.

 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.

 Anyway, std.traits wraps __traits reasonably well and doesn't 
 have the underscores.


__if (true) {

} __else {

}

__for (...) {

}

__enum {

}

That looks beautiful to you?
Nov 02 2013
parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Saturday, 2 November 2013 at 22:01:11 UTC, Namespace wrote:

 That looks beautiful to you?


In my ideal world, object.d would alias the __ versions back to 
the regular ones. (Really, it is int, long, etc. that I'd do like 
this, just like string. for, if, etc. are fine the way they are.)

The difference between that and the current thing is if the user 
did define their own thing, it could be disambiguated by the full 
name.
Nov 02 2013
prev sibling parent reply "Maxim Fomin" <maxim maxim-fomin.ru> writes:
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.
Nov 02 2013
parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Saturday, 2 November 2013 at 22:02:51 UTC, Maxim Fomin wrote:

 Statement that in D __identifiers are reserved is dubious as 
 nothing stops users from defining them


Yeah, but still, you aren't supposed to do it so you can't really 
complain when it breaks.
Nov 02 2013
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Nov 02, 2013 at 09:45:26PM +0100, TheFlyingFiddle wrote:

 I'm basically wondering why the __traits keyword looks so horrible.


Because the intention is that users would not use it directly, but via
nicer standard library wrappers (e.g. std.traits in Phobos).


T

-- 
I don't trust computers, I've spent too long programming to think that
they can get anything right. -- James Miller
Nov 02 2013
parent "TheFlyingFiddle" <theflyingfiddle gmail.com> writes:
On Saturday, 2 November 2013 at 23:01:51 UTC, H. S. Teoh wrote:

 On Sat, Nov 02, 2013 at 09:45:26PM +0100, TheFlyingFiddle wrote:

 I'm basically wondering why the __traits keyword looks so 
 horrible.


 Because the intention is that users would not use it directly, 
 but via
 nicer standard library wrappers (e.g. std.traits in Phobos).


 T


That makes sence.
Nov 02 2013