__FUNCTION__

[Edward Diener]

Andrei Alexandrescu wrote:
> BCS wrote:
>> Hello Andrei,
>>
>>> Nick Sabalausky wrote:
>>>
>>>> Stdout.formatln("{}", __FUNCTION__);
>>>
>>> I think instead of __FUNCTION__ we'll define a much more comprehensive
>>> static reflection facility.
>>>
>>
>> for the above case I think __FUNCTION__ is as good as it will get. 
>> Define it as a human readable identifier rather than reflection.
>>
>>
> 
> You will have it as a human readable identifier too. The problem with
> __FUNCTION__, __CLASS__ etc. is that the list of ad-hoc names (what
> happened to __STRUCT__, __MODULE__ et al?) can go forever.
> 

These macros are the wrong idea. As you say the bare macros can go on 
forever. What is really needed in a reflection library is the ability to 
  'reflect' all D constructs, and you would get much more than just the 
name in such a library.

So pushing for __FUNCTION__, __CLASS__ etc. etc. is just a quick-fix 
solution whereas a real reflection library gives so much more.

I argued for this in the past on this NG but still no one seems to have 
picked up the idea that a full reflection library for D, supported fully 
by the compiler, would be a great thing. It would also allow RAD 
programming with D outside of the functionality one could use in 3rd 
party tools designed around full run-time reflection capabilities.