== Quote from Matthew Ong (on...@yahoo.com)'s article > These 2 tokens are very useful for debugging and also trouble > shooting during exceptions time and even implementing logging > api similar to log4j:
> I do understand that this are compile time information and they > are static. > __FILE__ // prints something like D:\User\Project\...\MyMod.d > I do not like this full path format because it > might give hacker some idea when of server directory layout > structure for webbase cgi / layout, accidentally by junior > developer because of mis handled exceptions. This seems like a pretty weak reason (especially since it gives you the path of the *source file* in a compilation environment). > __LINE__ // some line number. > How about keeping those 2 and also adding some new compile time > information's tokens: > 1) __FILENAME__ // prints only MyMod.d Use CTFE. I don't disagree in principle with the idea of additional tokens, but I'm not sure the ones you're talking about make a lot of sense. I would like to see __COLUMN__, and I know adding it has been discussed, because it's the sort of thing one ought to be able to get from the compiler and it might be useful. One addition that I would advocate for whic isn't on your list is a token called __GENSYM__ (or perhaps __UNIQUE__ would be a better name), which returns a string that's guaranteed to be unique and usable as an identifier; this could provide additional safety when metaprogramming with mixin templates and string mixins. Right now you have to do hacky and not-terribly-robust things to synthesize unique IDs out of __FILE__ and __LINE__. Cheers, Pillsy