The Thermopylae excerpt of TDPL available online

[Don]

Lars T. Kyllingstad wrote:
> 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.
> 
> Do you mean in addition to or instead of the already proposed 
> traits/meta/compiler namespace?

It's another namespace suggestion. Just brainstorming.

> If it's just about avoiding new keywords I think this feature is 
> fundamental enough to deserve its own keyword, and all of the above are 
> more descriptive than 'scope'.
> 
> Is this "magic namespace" proposal technically difficult to implement in 
> the compiler?

See for yourself. For example, the patch below (against svn 234) allows 
'__traits' as the magic namespace. The existing __traits stuff continues 
to compile. <g>

__traits.compiles(XXX);
__traits.isArithmetic; // note, property syntax OK if no arguments
__traits.isArithmetic(int*);

(Any error messages involving __traits are wrong, of course).


Index: parse.c
===================================================================
--- parse.c	(revision 234)
+++ parse.c	(working copy)
@@ -4934,6 +4934,20 @@
  	    Objects *args = NULL;

  	    nextToken();
+	    if (token.value == TOKdot) {
+	        // __traits.identifier(args, ...)
+		nextToken();
+		if (token.value != TOKidentifier)
+		{   error("__traits.identifier(args...) expected");
+			goto Lerr;
+		}
+		ident = token.ident;
+		nextToken();
+		if (token.value==TOKlparen)
+		args = parseTemplateArgumentList2();
+	        e = new TraitsExp(loc, ident, args);
+		break;
+	    }
  	    check(TOKlparen);
  	    if (token.value != TOKidentifier)
  	    {   error("__traits(identifier, args...) expected");