http://d.puremagic.com/issues/show_bug.cgi?id=5140

           Summary: Add __FUNCTION__
           Product: D
           Version: unspecified
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: jmdavisProg@gmx.com


--- Comment #0 from Jonathan M Davis <jmdavisProg@gmx.com> 2010-10-30 20:28:59 PDT ---
D has __FILE__ and __LINE__ which give the file and line number where they're used. C/C++ has those as well, but (at least with some implementations) it also has __FUNCTION__ which gives the name of the function where it's used, which can be quite useful (especially when you use it in a logging message, and you don't necessarily know which version of the program the message comes from). So, I think that it would be benificial to add __FUNCTION__ to D. Honestly, I was surprised when it wasn't in the language while __FILE__ and __LINE__ were.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=5140


bearophile_hugs@eml.cc changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bearophile_hugs@eml.cc


--- Comment #1 from bearophile_hugs@eml.cc 2010-10-31 05:56:56 PDT ---
It also allows code like this, this recursive code will keep working even if "fact" gets renamed, it's more DRY:


long fact(long n) {
    if (n <= 1)
        return 1;
    else
        mixin("return n * " ~ __FUNCTION__ ~ "(n - 1);");
}
void main() {
    assert(fact(20) == 2_432_902_008_176_640_000);
}


But an alias of the current function is more handy for that purpose:

long fact(long n) {
    if (n <= 1)
        return 1;
    else
        return n * __function(n - 1);
}
void main() {
    assert(fact(20) == 2_432_902_008_176_640_000);
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=5140



--- Comment #2 from bearophile_hugs@eml.cc 2011-04-16 15:36:18 PDT ---
See a better explanations and some examples of __function: http://rosettacode.org/wiki/Anonymous_recursion

And I see this is another use case for __function:

http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.learn&article_id=26404

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=5140


Rob T <alanb@ucora.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |alanb@ucora.com


--- Comment #3 from Rob T <alanb@ucora.com> 2012-09-27 00:06:22 PDT ---
I'd like to add that __FUNCTION__ should operate in a consistent manner to __LINE__ and __FILE__ such that when used as a default value for a function parameter, the value is set where the function is called, not where the function is defined.

void Log( string funcname = __FUNCTION__)
{
  writeln( funcname );
}


void func1()
{
  Log(); // displays "func1"
}

void main()
{
  Log(); // displays "main"
}

To be more useful, the nested function names will have to prefixed with parent level function names, and probably also module name as the highest level.

void main()
{
  void func2()
  {
    Log(); // displays "main.func2"
  }
}

Member functions of class and struc should be prefixed with the class and struc names respectively.

For templates and overloaded functions, including the function signature would help resolve which version of a function was called. It may be best to have a separate version of __FUNCTION__ that displays the function signature, for example, C++ has __PRETTY_FUNCTION__ which includes the function signature.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=5140


Andrej Mitrovic <andrej.mitrovich@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |pull
                 CC|                            |andrej.mitrovich@gmail.com
            Version|unspecified                 |D2
         AssignedTo|nobody@puremagic.com        |andrej.mitrovich@gmail.com
         OS/Version|Linux                       |All


--- Comment #4 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2013-01-10 19:44:58 PST ---
https://github.com/D-Programming-Language/dmd/pull/1462

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=5140



--- Comment #5 from bearophile_hugs@eml.cc 2013-01-10 20:23:21 PST ---
If __FUNCTION__ gets approved, then probably the probability of __function getting approved decreases. And I don't care for __FUNCTION__.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=5140



--- Comment #6 from Rob T <alanb@ucora.com> 2013-01-10 23:24:01 PST ---
(In reply to comment #2)
> See a better explanations and some examples of __function: http://rosettacode.org/wiki/Anonymous_recursion
> 

I really would love to have the ability to perform anonymous recursion.

As for the name __FUNCTION__ I don't really like the convention either, but since it is related to __LINE__ and __FILE__, you'd probably have to depreciate those too so as to remain consistent.

This is great news if it gets accepted because I need it for log tracing, but I'd also like to see a version of this that displays the full function signature which allows you to see which overload or template version was called. I don't know if the patch does this or not.

--rt

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=5140



--- Comment #7 from Jonathan M Davis <jmdavisProg@gmx.com> 2013-01-11 00:05:34 PST ---
__FUNCTION__ is already used by some C/C++ compilers just like __FILE__ and __LINE__, so there's a fair bit of precedence for it, and it goes well with __FILE__ and __LINE__.

Personally, I don't care about anonymous recursion and see no need for them, but I don't see __FUNCTION__ as conflicting with __function at all. They do two entirely different things. __FUNCTION__ is a string, whereas __function is an alias to the function that it's used in.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=5140



--- Comment #8 from bearophile_hugs@eml.cc 2013-01-11 01:28:47 PST ---
Sorry Andrej, my last comment wasn't a critique of your good work in pull 1462.

(In reply to comment #7)

> but I don't see __FUNCTION__ as conflicting with __function at all. They do two entirely different things. __FUNCTION__ is a string, whereas __function is an alias to the function that it's used in.

I agree they are two quite different things, so probably I have to move the request for __function in another enhancement request.

But they are also related, as you can implement anonymous recursion with __FUNCTION__:


long fact(long n) {
    if (n <= 1)
        return 1;
    else
        mixin("return n * " ~ __FUNCTION__ ~ "(n - 1);");
}


So I think introducing __FUNCTION__ will make less likely the introduction of the __function alias. I hope to be wrong.


> Personally, I don't care about anonymous recursion and see no need for them,

Are you using recursion a lot in D? If you never use recursion in D, or you use it only once in thousand lines of code, then you don't have much need for language features that help using recursion, like __func (or private default arguments discussed recently).

If you use recursion often, an alias like __func or __function gets useful, because it allows you to write more DRY code, you write the function name only once. So renaming the function or other changes requires you to change only one name.

It's like the difference between D OOP and Java, this is Java-like code:

class Foo {
    Foo(int x) {...}
    void bar(Foo f) {
        Foo g = new Foo(5);
        ...
    }
}

This is one possible equivalent D code:

class Foo {
    this(int x) {...}
    void bar(typeof(this) f) {
        auto g = new typeof(this)(5);
        ...
    }
}

This D code contains the name Foo only once, this is more DRY, and it's useful.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=5140



--- Comment #9 from Jonathan M Davis <jmdavisProg@gmx.com> 2013-01-11 01:32:52 PST ---
I simply don't see any need to refer to a function anonymously when making a recursive call. You can just use its name like you do anywhere else that you call it. The _only_ advantage that I see is that you have fewer lines of code to change when you change the function's name, but search and replace takes care of that quite easily.

I'm not necessarily against the inclusion of __function. I just don't find the idea useful enough to care.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------