"Robert Clipsham" <rob...@octarineparrot.com> wrote in message news:hcg0qr$fc...@digitalmars.com... > Don wrote: >> I'm starting to think we need a >>> separate namespace for the CT stuff. >>> >>> D.compiles(XXX) >>> D.typeof(foo) >>> D.stringof(T) >>> D.allMembers(T) >> >> That's not bad. Can't be 'D', though, has to look like a keyword. Maybe >> something like 'traits' instead. In exchange, get rid of the '__traits' >> and 'typeid' keywords. Not sure about typeof, though. >> >> traits.compiles(XXX) >> traits.typeid(TTT) >> traits.stringof(T) >> traits.allMembers(T) >> traits.error("message"); >> >> IMHO this looks better than __traits(compiles, XXX) but it actually has >> the same flexibility, and it's a straightforward transformation inside >> the compiler. >> For bonus points, allow 'with(traits)': >> >> with(traits) { >> if (compiles(XXX)) return stringof(T); >> else error("Can't use " ~ stringof(T) ~ " in a transmogrifier."); >> } >> > > This could even be implemented in phobos (or object.d to avoid an import > when you want to use it), using something like: > > pragma(traits) struct traits > { > // Members automatically added by the compiler, or maybe just their > // declarations eg: > static T delegate()[] allMembers(T)(T type); > } > > This way there's no need to force a certain name, as it can be chosen by > the developer (by either using renaming imports or just giving the struct > a different name eg pragma(traits) struct meta {}).
I'm not sure I see the value in being able to rename that. That's like making sure people can rename "for".
