• Frank Benoit (5/5) Nov 11 2007 When __traits was introduced, it was said, this will probably change
• Robert Fraser (2/9) Nov 11 2007 I'm down with that. The main problem is identifiers named traits (in par...
• Bill Baxter (3/14) Nov 11 2007 There's the same issue with string and std.string. It works somehow.
• Daniel Keep (10/28) Nov 11 2007 No, it's not; they're completely different. 'string' is an alias
• Robert Fraser (4/37) Nov 12 2007 I find traits very useful. For example, I have a template that can be mi...

Frank Benoit <keinfarbton googlemail.com> writes:

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?

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

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

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

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.