The Thermopylae excerpt of TDPL available online

[grauzone]

Don wrote:
> Jason House wrote:
>> Don Wrote:
>>
>>> Leandro Lucarella wrote:
>>>> Justin Johansson, el 30 de octubre a las 08:42 me escribiste:
>>>>>> Actually, I think I like that better than 'traits'.
>>>>>>
>>>>>> -Lars
>>>>> I'm in agreement with whoever suggested 'meta' or just about 
>>>>> anything else except  'traits'.
>>>>> 'meta', whilst perhaps an overloaded keyword, is still much more 
>>>>> user-friendly.  Whenever
>>>>> I see 'traits' I get the feeling I need a Ph.D. to understand what 
>>>>> it's about.  For some reason,
>>>>> I don't know why, 'meta' has an aire of karma about it.
>>>> "compiler"? That could open the door to other types of access to 
>>>> compiler
>>>> internals, AST, etc.
>>> Yup. I think the 'magic namespace' approach is a simple, clean way to 
>>> incorporate reflection. It could be like Object and TypeInfo, 
>>> implicitly available in every module and tightly coupled to the 
>>> compiler, but can be viewed by the user as if it were just a module. 
>>> It'd be particularly interesting if some of the functions _were_  
>>> actually implemented in library code, when possible.
>>
>> What about going one step further? You could require an import 
>> statement to use traits. For example, import traits=std.traits could 
>> reproduce your earlier suggestion, but gives added flexibility to the 
>> programmer. It also eliminates a keyword.
> 
> It's too fundamental for that. You can't use template constraints 
> without it.
> BTW, 'scope' is another possible magic namespace.
> 
> scope.compiles(XXX) -- true if XXX compiles in the current scope.
> 
> More generally, scope.YYY()  would provide metaprogramming information 
> about the property YYY of the current scope.

I suggest we use static. static.YYY(), doesn't look that lovely?