Isn't __FILE__ really just a macro? it's processed before tokenizing! according to the specc, if the lexer sees __FILE__ or __LINE__ or such, it should convert it to an appropriate string/number/whatever before tokenizing it. Hence, it's a macro.

This implies that __FILE__ and such cannot be used in mixins or templates to mimic things like the following C macro:

#define log(s) logprintf(__FILE__ ": " __FUNCTION__ ": %s", s)

Shouldn't these things become templates (or something like that) so that we can use them like the above C macro, but with D templates?

Hasan Aljudy wrote:
> Isn't __FILE__ really just a macro? it's processed before tokenizing! according to the specc, if the lexer sees __FILE__ or __LINE__ or such, it should convert it to an appropriate string/number/whatever before tokenizing it. Hence, it's a macro.
> 

__FILE__ is processed (like __LINE__) as a special reserved identifier which tokenizes to a string representing the current source file being tokenized.

It is _not_ processed _before_ tokenization as you say; it is processed during tokenization and is converted to an equivalent string-literal token.

> This implies that __FILE__ and such cannot be used in mixins or templates to mimic things like the following C macro:

I'm not sure how you concluded that... Are you asking to which source file the __FILE__ reserved identifier represents when using a mixin across file boundaries?

> 
> #define log(s) logprintf(__FILE__ ": " __FUNCTION__ ": %s", s)
> 
> Shouldn't these things become templates (or something like that) so that we can use them like the above C macro, but with D templates?

Perhaps you're hinting at a new set of reserved words like __INSTANTIATED_FILE__ and __INSTANTIATED_FUNCTION__ so that they expand to the file/line number where the template/mixin is instantiated at?

-- 
Regards,
James Dunne