On 19/09/2012 08:24, Jacob Carlborg wrote:
On 2012-09-19 01:21, Rob T wrote:
Actually I find the __traits system a bit convoluted and inconsistent
with other similar features. There seems to be a real need to unify the
different methods of reflection in D.
For example, I can do this without using __traits
int i;
writeln( i.stringof );
and I can do this
void function x() {};
writeln( x.stringof );
but it won't work for the main function
int main(char[][] args)
{
writeln( main.stringof ); // compile error (bug?)
}
I think the reason for this is that the compiler will resolve "main" as
a function call, but it will fail because no arguments are given. This
is a typical feature where it seems no one really know how it should
behave. .stringof is very poorly documented. It says nothing about what
the returned string might look like.
I don't think that's true, is it? It would be true if main was marked
@property, but it isn't, so it's only a call if you have () after it.
I'd expect "main" to resolve to either a function or (if overloaded) a
function set, and then - if it's not a set - you could pass it around
like a C function pointer. (If it is a set, I have no idea.)
but this works
writeln(__traits( identifier, main ));
It seems that __traits(itentifier, ) and .stringof are two ways of
getting access to the same information.
Hmm, it does seem that way, doesn't it?
So why do we have __traits and the built in properties that overlap in
functionality? Why is it inconsistently applied as seen with function
main (although that could simply be a bug)? The situation is rather
confusing.
.stringof was available long before D2 was created, __traits is only
available in D2. I think __traits was create to try to improve the
compile time reflection abilities in D.
If it helps, I recently discovered the std.traits library, which wraps a
lot of those ugly low-level-looking things in cleaner-looking things. I
couldn't see the 'self' use case in there though.
