On 2012-46-06 08:11, Don Clugston <dac@nospam.com> wrote:

> 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.

DMD already does some cycle detection for types, right? I don't remember
the details, but i seem to recall this was made to work a few releases back:

class Foo {
    static if ( is( typeof( Foo.bar ) ) ) {
        void baz() {}
    }
    static if ( true ) {
        int bar() {}
    }
}

The algorithm would probably have to exclude mixins, but I think it could
be made to work for most cases.

-- 
Simen

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.

On Tuesday, 6 November 2012 at 07:46:47 UTC, Don Clugston wrote:
>
> 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').
>

In our case, the function name that is returned is nothing but the function's symbol name by itself, which of course is known ahead of time no matter if auto is stated or not. This is why it seems more like a bug to me.


--rt