http://d.puremagic.com/issues/show_bug.cgi?id=5140
--- Comment #12 from Don <[email protected]> 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: -------
