keyword __traits

[Robert Fraser]

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.