Simple implementation of __FUNCTION

[r_m_r]

I don't know how I missed this thread. I was having the same 
'forward reference' error and after a brief chat on #D IRC, 
thought it might be a compiler bug and reported it as such: 
http://d.puremagic.com/issues/show_bug.cgi?id=8963 . Should I 
close this issue?

Any thoughts on possible workarounds?

BTW I've been 'mixing'-in this template in all my functions (for 
debugging):

//---- Code ---
import std.traits : PIT=ParameterIdentifierTuple;

template dbg(string msg)
{
     const char[] dbg = "writeln( src(\"DBG\",
                                     __traits(identifier, 
__traits(parent, {})) ~
                                     
_params_join([PIT!(__traits(parent,{}))]),
                                     " ~ msg ~ "
                                     )
                                );" ;
}
//----- Code ---

Its working great except for the "auto"-return functions.

rmr

On Tuesday, 6 November 2012 at 07:46:47 UTC, Don Clugston wrote:
> On 06/11/12 07:09, Rob T wrote:
>> On Friday, 2 November 2012 at 22:33:37 UTC, Rob T wrote:
>>> I discovered it fails to compile when inside a function with 
>>> "auto" as
>>> the return type.
>>>
>>> auto test()
>>> {
>>>   throw new Exception(  mixin(__FUNCTION) );
>>>   return 0;
>>> }
>>>
>>> Error: forward reference to test
>>>
>>> but this works
>>>
>>> int test()
>>> {
>>>   throw new Exception(  mixin(__FUNCTION) );
>>>   return 0;
>>> }
>>>
>>> So we're kinda sunk for inclusion in phobos unless this error 
>>> can be
>>> resolved.
>>>
>>> I'll try the enum idea to see if that works.
>>>
>>> --rt
>>
>> An update on this problem. I found out that the error when 
>> using auto as
>> return type has nothing to do with the mixin. The compiler 
>> error
>> persists when you take mixin out and put in the __traits( ... 
>> ) code
>> directly.
>>
>> Does anyone else think that this is a compiler bug? If it is a 
>> bug then
>> I'll report it in the bug tracker.
>>
>> --rt
>
> It fails because you're asking for the full function name, 
> before its type has been determined. (There's no real return 
> type 'auto', 'auto' just means 'work it out for me').
>
> I don't think this is a bug. Although it might be solvable in 
> this particular example, in general it's a circular dependency.
>
> eg, if you do:
>
> auto foo()
> {
>    static if (__FUNCTION == "int foo()") { return 'a' }
>    return 0;
> }
> if __FUNCTION is "int foo()" then it will return a char, which 
> means its signature is "char foo()". This is a contradiction.