Re: Simple implementation of __FUNCTION

[Simen Kjaeraas]

On 2012-46-06 08:11, Don Clugston d...@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

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

Re: Simple implementation of __FUNCTION

[Rob T]

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

Re: Simple implementation of __FUNCTION

[Rob T]

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

Re: Simple implementation of __FUNCTION

[Don Clugston]

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.

Re: Simple implementation of __FUNCTION

[Damian]

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 :)

Re: Simple implementation of __FUNCTION

[Rob T]

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

Re: Simple implementation of __FUNCTION

[Jacob Carlborg]

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

Re: Simple implementation of __FUNCTION

[Rob T]

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?

Re: Simple implementation of __FUNCTION

[Adam D. Ruppe]

On Friday, 2 November 2012 at 17:31:55 UTC, Rob T wrote:
Thanks to input from the D community, I've managed to implement 
a reasonable way to log the name of a calling function.


Huh, that's pretty brilliant!


The ONLY thing left that I would like to have, is ability to 
display the function signature along with the name.


template __FUNCTION_SIGNATURE() { const char[] 
__FUNCTION_SIGNATURE = typeof(__traits(parent, {})).stringof; }


int main(string[] args) {
assert(0, mixin(__FUNCTION_SIGNATURE!()));
}

core.exception.AssertError@test4.d(7): int(string[] args)

Re: Simple implementation of __FUNCTION

[Alex Rønne Petersen]

On 02-11-2012 18:31, Rob T wrote:

Thanks to input from the D community, I've managed to implement a
reasonable way to log the name of a calling function. This is used for
basic execution monitoring and for automated logging of exception errors.

Here's what I did.

template __FUNCTION()
{
const char[] __FUNCTION = __traits(identifier, __traits(parent, {}));
}

Example use in code:

throw new Exception( Error: Function , mixin(__FUNCTION!()) );

writefln( File: %s, Func: %s, Line: %d, __FILE__,
mixin(__FUNCTION!()), __LINE__ );


The ONLY thing left that I would like to have, is ability to display the
function signature along with the name. The signature will be very
useful to show which version of an overloaded or templated function was
called.

If anyone can suggest imporvements, like how to get rid of need to
explicitly call mixin, and better yet a solution to get the function
signature, please post away. Thanks!

I have to mention that we need a real solution that can only be provided
through improved reflection support, eg __scope.function, __scope.line,
__scope.file, etc, or whatever the D community thinks will fit in best.

--rt




You should totally submit this for inclusion into std.traits in Phobos.

(Though, to follow naming conventions, it should be functionName and 
functionSignature or so.)


--
Alex Rønne Petersen
a...@lycus.org
http://lycus.org

Re: Simple implementation of __FUNCTION

[Regan Heath]

On Fri, 02 Nov 2012 18:06:19 -, Alex Rønne Petersen a...@lycus.org  
wrote:



On 02-11-2012 18:31, Rob T wrote:

Thanks to input from the D community, I've managed to implement a
reasonable way to log the name of a calling function. This is used for
basic execution monitoring and for automated logging of exception  
errors.


Here's what I did.

template __FUNCTION()
{
const char[] __FUNCTION = __traits(identifier, __traits(parent,  
{}));

}

Example use in code:

throw new Exception( Error: Function , mixin(__FUNCTION!()) );

writefln( File: %s, Func: %s, Line: %d, __FILE__,
mixin(__FUNCTION!()), __LINE__ );


The ONLY thing left that I would like to have, is ability to display the
function signature along with the name. The signature will be very
useful to show which version of an overloaded or templated function was
called.

If anyone can suggest imporvements, like how to get rid of need to
explicitly call mixin, and better yet a solution to get the function
signature, please post away. Thanks!

I have to mention that we need a real solution that can only be provided
through improved reflection support, eg __scope.function, __scope.line,
__scope.file, etc, or whatever the D community thinks will fit in best.

--rt




You should totally submit this for inclusion into std.traits in Phobos.

(Though, to follow naming conventions, it should be functionName and  
functionSignature or so.)


+1 :)

R

--
Using Opera's revolutionary email client: http://www.opera.com/mail/

Re: Simple implementation of __FUNCTION

[H. S. Teoh]

On Fri, Nov 02, 2012 at 07:06:19PM +0100, Alex Rønne Petersen wrote:
 On 02-11-2012 18:31, Rob T wrote:
[...]
 template __FUNCTION()
 {
 const char[] __FUNCTION = __traits(identifier, __traits(parent, {}));
 }
 
 Example use in code:
 
 throw new Exception( Error: Function , mixin(__FUNCTION!()) );
 
 writefln( File: %s, Func: %s, Line: %d, __FILE__,
 mixin(__FUNCTION!()), __LINE__ );
[[...]
 You should totally submit this for inclusion into std.traits in Phobos.
 
 (Though, to follow naming conventions, it should be functionName and
 functionSignature or so.)
[...]

+1.


T

-- 
Тише едешь, дальше будешь.

Re: Simple implementation of __FUNCTION

[mist]

Sweet! You may also find my pull request for phobos ( #863, 
fullyQualifiedTypename ) useful for adding function signature 
once it gets finalised and merged.


On Friday, 2 November 2012 at 17:31:55 UTC, Rob T wrote:
Thanks to input from the D community, I've managed to implement 
a reasonable way to log the name of a calling function. This is 
used for basic execution monitoring and for automated logging 
of exception errors.


Here's what I did.

template __FUNCTION()
{
   const char[] __FUNCTION = __traits(identifier, 
__traits(parent, {}));

}

Example use in code:

throw new Exception( Error: Function , mixin(__FUNCTION!()) );

writefln( File: %s, Func: %s, Line: %d, __FILE__, 
mixin(__FUNCTION!()), __LINE__ );



The ONLY thing left that I would like to have, is ability to 
display the function signature along with the name. The 
signature will be very useful to show which version of an 
overloaded or templated function was called.


If anyone can suggest imporvements, like how to get rid of need 
to explicitly call mixin, and better yet a solution to get the 
function signature, please post away. Thanks!


I have to mention that we need a real solution that can only be 
provided through improved reflection support, eg 
__scope.function, __scope.line, __scope.file, etc, or whatever 
the D community thinks will fit in best.


--rt

Re: Simple implementation of __FUNCTION

[Jacob Carlborg]

On 2012-11-02 18:31, Rob T wrote:

Thanks to input from the D community, I've managed to implement a
reasonable way to log the name of a calling function. This is used for
basic execution monitoring and for automated logging of exception errors.

Here's what I did.

template __FUNCTION()
{
const char[] __FUNCTION = __traits(identifier, __traits(parent, {}));
}

Example use in code:

throw new Exception( Error: Function , mixin(__FUNCTION!()) );

writefln( File: %s, Func: %s, Line: %d, __FILE__,
mixin(__FUNCTION!()), __LINE__ );


That's pretty darn cool, well done :D .

--
/Jacob Carlborg

Re: Simple implementation of __FUNCTION

[Rob T]

On Friday, 2 November 2012 at 17:55:33 UTC, Adam D. Ruppe wrote:
The ONLY thing left that I would like to have, is ability to 
display the function signature along with the name.


template __FUNCTION_SIGNATURE() { const char[] 
__FUNCTION_SIGNATURE = typeof(__traits(parent, {})).stringof; 
}


int main(string[] args) {
assert(0, mixin(__FUNCTION_SIGNATURE!()));
}

core.exception.AssertError@test4.d(7): int(string[] args)


That was fast, thanks!

template __PRETTY_FUNCTION()
{
	const char[] __PRETTY_FUNCTION = __traits(identifier, 
__traits(parent, {})) ~  ~ __FUNCTION_SIGNATURE!();

}


--rt

Re: Simple implementation of __FUNCTION

[Philippe Sigaud]

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?

Re: Simple implementation of __FUNCTION

[Jonathan M Davis]

On Friday, November 02, 2012 22:34:15 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?

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.

- Jonathan M Davis

Re: Simple implementation of __FUNCTION

[Timon Gehr]

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, {})) };

Re: Simple implementation of __FUNCTION

[Philippe Sigaud]

On Fri, Nov 2, 2012 at 10:59 PM, Jonathan M Davis jmdavisp...@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.

Re: Simple implementation of __FUNCTION

[Rob T]

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

Re: Simple implementation of __FUNCTION

[Rob T]

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