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?
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?
-Lars