The Thermopylae excerpt of TDPL available online

[Nick Sabalausky]

"Robert Clipsham" <robert at octarineparrot.com> wrote in message 
news:hcg0qr$fce$1 at 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".