Self function

[Denis Koroskin]

On Mon, 04 May 2009 23:52:56 +0400, bearophile <bearophileHUGS at lycos.com> wrote:

> Sometimes I rename recursive functions, or I duplicate and modify them,  
> and they stop working because inside them there's one or more copy of  
> their old name, so for example they recurse to their old name.
> So inside a function I'd like to have a standard name to call the  
> function itself, useful for recursivity.
> (If you have two or more recursive functions that call each other this  
> idea can't be used, but I think such situations are uncommon enough to  
> not deserve help from the language).
>
> I have just discussed this in the Python newsgroup too:
> http://groups.google.com/group/comp.lang.python/browse_thread/thread/d265da85d4b70eaf#
>
> I use more recursivity in D than in Python, because Python has troubles  
> with it.
>
> In future in D2 you may use:
>
> int ANUGLYNAME(int n) {
>     if (n <= 1)
>         return 1;
>     else
>         mixin(__FUNCTION__ ~ "(n - 1) * n");
> }
>
> But you can't use __FUNCTION__ into a delegate/function pointer/lambda  
> because the name isn't available, and it's a bit ugly syntax anyway...
>
> This looks a bit better:
>
> int ANUGLYNAME(int n) {
>     if (n <= 1)
>         return 1;
>     else
>         __self(n - 1) * n;
> }
>
> Other syntaxes are possible.
>
> __self is a way to denote the pointer/delegate of the function currently  
> being run, so I think the compiler is always able to that, for delegate/  
> function pointers/ lambdas/ methods/ virtual methods/ opCalls too.
>
> Bye,
> bearophile

It was proposed awhile ago: http://www.digitalmars.com/d/archives/digitalmars/D/FUNCTION_84985.html

Andrei's respond:

"I think instead of __FUNCTION__ we'll define a much more comprehensive 
static reflection facility."

"You will have it as a human readable identifier too. The problem with
__FUNCTION__, __CLASS__ etc. is that the list of ad-hoc names (what
happened to __STRUCT__, __MODULE__ et al?) can go forever."

"D2 will have reflection. (Walter doesn't know yet. He thinks D3 will 
have reflection.) It will be compile-time reflection because only 
run-time reflection only is missing the point."


"This is a long discussion, but in brief any runtime reflection engine 
needs some sort of compile-time metadata infrastructure. Some languages 
don't make that accessible within the language itself. Runtime 
reflection has been explored extensively, its possibilities and 
limitations are pretty well understood, I hardly smothered a yawn 
reading all you wrote. Compile-time reflection is much less understood 
and hides many more exciting possibilities. With the advances in 
compiler technology implemented by Walter, we have a chance to tackle 
reflection in a systematic manner."