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



--- Comment #10 from bearophile_hugs@eml.cc 2013-01-11 01:54:52 PST ---
(In reply to comment #9)
> 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.

Do you mean you wish/prefer to write OOP like this in D?


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

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


Jacob Carlborg <doob@me.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |doob@me.com


--- Comment #11 from Jacob Carlborg <doob@me.com> 2013-01-11 02:33:23 PST ---
(In reply to comment #8)
> 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.

Can't __FUNCTION__ be implemented like this:

__traits(identifier, __function);

That is, if __function gets implemented.

-- 
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 #12 from Don <clugdbug@yahoo.com.au> 2013-01-11 04:52:46 PST ---
(In reply to comment #11)
> (In reply to comment #8)
> > 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.
> 
> Can't __FUNCTION__ be implemented like this:
> 
> __traits(identifier, __function);
> 
> That is, if __function gets implemented.

No. It needs magical treatment when used as a default parameter.

-- 
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 #13 from Jacob Carlborg <doob@me.com> 2013-01-11 05:02:28 PST ---
(In reply to comment #12)

> No. It needs magical treatment when used as a default parameter.

Right, didn't think of that.

-- 
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 #14 from Rob T <alanb@ucora.com> 2013-01-11 09:29:13 PST ---
(In reply to comment #10)
> (In reply to comment #9)
> > 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.
> 
> Do you mean you wish/prefer to write OOP like this in D?
> 
> 
> class Foo {
>     Foo(int x) {...}
>     void bar(Foo f) {
>         Foo g = new Foo(5);
>         ...
>     }
> }

Good points. I know what you say is true because I use recursion often enough to see the advantages. The case for private default args is another solid argument.

More generically speaking however, rather than being ad-hoc less-than-useful, what is being proposed actually makes some of D's features more consistent with the rest of D. For example the use of private args is more consistent with the rest of D's features that already have private, such as structs, classes, and modules. Disallowing private args is actually less consistent with the rest of D and is a throw-back to the C era. The _function is actually consistent with the use of "this" for structs and classes. Had these private args and anonymous recursion been implemented from the start, the thought of removing them would never be considered. If we had the chance to redesign D, we could actually make it simpler to use and more powerful by making it more consistent.

--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 #15 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2013-01-11 10:04:38 PST ---
The pull now implements __FUNCTION__ and __PRETTY_FUNCTION__. You can take a look at the test-case for examples, but in short:

1) __FUNCTION__ as a statement inside a function => fully-qualified name of the
current function
2) __FUNCTION__ as a default init for a parameter => fully-qualified name of
the calling function

3) __PRETTY_FUNCTION__ as a statement inside a function => same as #1 + parameters, return type, and modifiers.

4) __PRETTY_FUNCTION__ as a default init for a parameter => same as #2 + parameters, return type, and modifiers.

If either of these is called in module scope (e.g. enum which is initialized with UFCS), it will return an empty string.

-- 
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 #16 from bearophile_hugs@eml.cc 2013-01-11 10:28:43 PST ---
(In reply to comment #15)

> If either of these is called in module scope (e.g. enum which is initialized with UFCS), it will return an empty string.

A question: isn't it better to give a compilation error in this case, instead of returning an empty result?

-- 
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 #17 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2013-01-11 12:31:38 PST ---
(In reply to comment #16)
> (In reply to comment #15)
> 
> > If either of these is called in module scope (e.g. enum which is initialized with UFCS), it will return an empty string.
> 
> A question: isn't it better to give a compilation error in this case, instead of returning an empty result?

No, because it would make the function unusable in CTFE in some contexts.

-- 
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
----------------------------------------------------------------------------
            Summary|Add __FUNCTION__ and        |Add __FUNCTION__,
                   |__PRETTY_FUNCTION__         |__PRETTY_FUNCTION__, and
                   |                            |__MODULE__


--- Comment #18 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2013-01-11 16:36:57 PST ---
The enhancemented now includes __MODULE__ as requested by Andrei and others.

-- 
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
----------------------------------------------------------------------------
                 CC|                            |georg@iki.fi


--- Comment #19 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2013-01-11 19:39:54 PST ---
*** Issue 2909 has been marked as a duplicate of this issue. ***

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