www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Re: keyword __traits

reply Robert Fraser <fraserofthenight gmail.com> writes:
Frank Benoit Wrote:

 When __traits was introduced, it was said, this will probably change
 again, and that "__traits" is ugly.
 
 So I want to bring that up again, as a remainder. And also I want to ask
 for suggestions.
 
 Why not simply have "traits" without the underscores as the keyword?

I'm down with that. The main problem is identifiers named traits (in particular, I believe std.traits, which may be used by quite a few projects).
Nov 11 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Robert Fraser wrote:
 Frank Benoit Wrote:
 
 When __traits was introduced, it was said, this will probably change
 again, and that "__traits" is ugly.

 So I want to bring that up again, as a remainder. And also I want to ask
 for suggestions.

 Why not simply have "traits" without the underscores as the keyword?

I'm down with that. The main problem is identifiers named traits (in particular, I believe std.traits, which may be used by quite a few projects).

There's the same issue with string and std.string. It works somehow. --bb
Nov 11 2007
parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Bill Baxter wrote:
 Robert Fraser wrote:
 Frank Benoit Wrote:

 When __traits was introduced, it was said, this will probably change
 again, and that "__traits" is ugly.

 So I want to bring that up again, as a remainder. And also I want to ask
 for suggestions.

 Why not simply have "traits" without the underscores as the keyword?

I'm down with that. The main problem is identifiers named traits (in particular, I believe std.traits, which may be used by quite a few projects).

There's the same issue with string and std.string. It works somehow. --bb

No, it's not; they're completely different. 'string' is an alias defined in the standard library; it's not a reserved word. 'traits' would be a reserved word, which will break anything that uses the word 'traits'. Besides, I think Walter has said on a few occasions that __traits is for internal library use; I think he wants to have a higher-level interface exposed via a library, in which case, it doesn't matter what __traits is called, since no one will be expected to use it. -- Daniel
Nov 11 2007
parent Robert Fraser <fraserofthenight gmail.com> writes:
Daniel Keep Wrote:

 
 
 Bill Baxter wrote:
 Robert Fraser wrote:
 Frank Benoit Wrote:

 When __traits was introduced, it was said, this will probably change
 again, and that "__traits" is ugly.

 So I want to bring that up again, as a remainder. And also I want to ask
 for suggestions.

 Why not simply have "traits" without the underscores as the keyword?

I'm down with that. The main problem is identifiers named traits (in particular, I believe std.traits, which may be used by quite a few projects).

There's the same issue with string and std.string. It works somehow. --bb

No, it's not; they're completely different. 'string' is an alias defined in the standard library; it's not a reserved word. 'traits' would be a reserved word, which will break anything that uses the word 'traits'. Besides, I think Walter has said on a few occasions that __traits is for internal library use; I think he wants to have a higher-level interface exposed via a library, in which case, it doesn't matter what __traits is called, since no one will be expected to use it. -- Daniel

I find traits very useful. For example, I have a template that can be mixed into any D2 class that generates toHash and opEquals functions based on the members, and one that generates a binary serialization function. Both use traits. Of course, not actually _using_ D2 very often, I don't get the chance to play around with them much, but I think it's a very neat feature to have exposed to the user, and no more for "internal library use" than any other compile-time construct (is expressions, mixins, typeid, etc.) At first, the underscores scared me off, but at this point, I really don't care either way. If it does change, though, I hope __traits is retained as a synonym at last for a few releases. As a side note, I really like the extensible manner in which traits expressions are formed, I can see the construct becoming ever more flexible in future releases.
Nov 12 2007