On 11/02/2012 10:34 PM, Philippe Sigaud wrote:
> By changing this to a standard function:
>
> const(char[]) __FUNCTION() @property
> {
>     return "__traits(identifier, __traits(parent, {}))";
> }
>
>
> ... the calling syntax is slightly easier on the eye:
>
> void main()
> {
>      writefln( "File: %s, Func: %s, Line: %d", __FILE__,
> mixin(__FUNCTION), __LINE__ );
>
>      //throw new Exception( "Error: Function " ~ mixin(__FUNCTION) );
> }
>
> That is, mixin(__FUNCTION) instead of mixin(__FUNCTION!())
>
>
> Is there any downside to this?
>

I'd make it

enum currentFunction = q{ __traits(identifier, __traits(parent, {})) };

On Fri, Nov 2, 2012 at 10:59 PM, Jonathan M Davis <jmdavisProg@gmx.com> wrote:

>> Is there any downside to this?
>
> Identifiers starting with __ are reserved for the compiler/language. It should be __FUNCTION__ if it's built-in, but if it's in the library, I see no reason to name it in a way that conflicts with Phobos' naming conventions like this.

Er, yes, but __FUNCTION comes the OP. My question was more about using
a function instead of a template.
And Timon makes a good point, using a token string q{ } should make
this more mixin-able.

On Friday, 2 November 2012 at 21:34:23 UTC, Philippe Sigaud wrote:
> By changing this to a standard function:
>
> const(char[]) __FUNCTION() @property
> {
>    return "__traits(identifier, __traits(parent, {}))";
> }
>
>
> ... the calling syntax is slightly easier on the eye:
>
> void main()
> {
>     writefln( "File: %s, Func: %s, Line: %d", __FILE__,
> mixin(__FUNCTION), __LINE__ );
>
>     //throw new Exception( "Error: Function " ~ mixin(__FUNCTION) );
> }
>
> That is, mixin(__FUNCTION) instead of mixin(__FUNCTION!())
>
>
> Is there any downside to this?

That looks better. Not sure what the down side would be if any.

Unrelated to either form, 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

On Friday, 2 November 2012 at 22:33:37 UTC, Rob T wrote:
>
> Unrelated to either form, 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

No luck with enum version, it still fails to compile when used inside a function with auto as the return type, same "forward reference" error.

--rt

On 2012-11-02 23:33, Rob T wrote:

> That looks better. Not sure what the down side would be if any.
>
> Unrelated to either form, 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 think it would be worth to but in Phobos anyway.

-- 
/Jacob Carlborg

On Saturday, 3 November 2012 at 11:09:48 UTC, Jacob Carlborg wrote:
>
> I think it would be worth to but in Phobos anyway.

I suppose it works as a temp solution until a real one is finally implemented, or maybe the mixin behaviour is considered a bug and can be fixed?

On Saturday, 3 November 2012 at 17:04:31 UTC, Rob T wrote:
> On Saturday, 3 November 2012 at 11:09:48 UTC, Jacob Carlborg wrote:
>>
>> I think it would be worth to but in Phobos anyway.
>
> I suppose it works as a temp solution until a real one is finally implemented, or maybe the mixin behaviour is considered a bug and can be fixed?

I think __FUNCTION__ should be built into the compiler, with it's brothers __FILE__ and __LINE__ . This kinda thing is so useful while debugging and logging :)

On Sunday, 4 November 2012 at 13:57:07 UTC, Damian wrote:
> On Saturday, 3 November 2012 at 17:04:31 UTC, Rob T wrote:
>> On Saturday, 3 November 2012 at 11:09:48 UTC, Jacob Carlborg wrote:
>>>
>>> I think it would be worth to but in Phobos anyway.
>>
>> I suppose it works as a temp solution until a real one is finally implemented, or maybe the mixin behaviour is considered a bug and can be fixed?
>
> I think __FUNCTION__ should be built into the compiler, with it's brothers __FILE__ and __LINE__ . This kinda thing is so useful while debugging and logging :)

I completely agree. Direct compiler support is the only way to implement this form of reflection reliably for all cases. Also consider that with D we have an opportunity to implement reflection features in a more consistent way through a generlized form of reflection.

--rt

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

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.