[Issue 5140] Add __FUNCTION__, __PRETTY_FUNCTION__, and __MODULE__
http://d.puremagic.com/issues/show_bug.cgi?id=5140 Andrej Mitrovic changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5140] Add __FUNCTION__, __PRETTY_FUNCTION__, and __MODULE__
http://d.puremagic.com/issues/show_bug.cgi?id=5140 --- Comment #23 from github-bugzi...@puremagic.com 2013-03-06 20:02:48 PST --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/1822acb7a47ae71c3889db2c26efbfb7d1c64c5c Fixes Issue 5140 - Implement __FUNCTION__, __PRETTY_FUNCTION__, and __MODULE__ feature. https://github.com/D-Programming-Language/dmd/commit/fd628d8170730cf01f318e1b15e0d894be358f17 Merge pull request #1462 from AndrejMitrovic/Fix5140 [enh] Issue 5140 - Implement __FUNCTION__, __PRETTY_FUNCTION__ and __MODULE__ -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5140] Add __FUNCTION__, __PRETTY_FUNCTION__, and __MODULE__
http://d.puremagic.com/issues/show_bug.cgi?id=5140 --- Comment #22 from bearophile_h...@eml.cc 2013-01-12 13:47:44 PST --- (In reply to comment #20) > Please make another enhancement request for this, so it's not forgotten and we > can wait for a separate approval. OK. See Issue 9306 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5140] Add __FUNCTION__, __PRETTY_FUNCTION__, and __MODULE__
http://d.puremagic.com/issues/show_bug.cgi?id=5140 --- Comment #21 from Andrej Mitrovic 2013-01-12 10:42:15 PST --- (In reply to comment #8) > 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);"); > } This is unreliable. If `fact` is nested inside of a mixin template you won't be able to call the function this way. On another note this has uncovered a new ICE in Issue 9182. It's also very untidy to have to use mixins and string representation for recursive calls. It's much simpler to use 'return __function(n - 1)'. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5140] Add __FUNCTION__, __PRETTY_FUNCTION__, and __MODULE__
http://d.puremagic.com/issues/show_bug.cgi?id=5140 --- Comment #20 from Andrej Mitrovic 2013-01-12 10:28:13 PST --- (In reply to comment #8) > > 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. Please make another enhancement request for this, so it's not forgotten and we can wait for a separate approval. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5140] Add __FUNCTION__, __PRETTY_FUNCTION__, and __MODULE__
http://d.puremagic.com/issues/show_bug.cgi?id=5140 Andrej Mitrovic changed: What|Removed |Added CC||ge...@iki.fi --- Comment #19 from Andrej Mitrovic 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: ---
[Issue 5140] Add __FUNCTION__, __PRETTY_FUNCTION__, and __MODULE__
http://d.puremagic.com/issues/show_bug.cgi?id=5140 Andrej Mitrovic changed: What|Removed |Added Summary|Add __FUNCTION__ and|Add __FUNCTION__, |__PRETTY_FUNCTION__ |__PRETTY_FUNCTION__, and ||__MODULE__ --- Comment #18 from Andrej Mitrovic 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: ---
[Issue 5140] Add __FUNCTION__ and __PRETTY_FUNCTION__
http://d.puremagic.com/issues/show_bug.cgi?id=5140 --- Comment #17 from Andrej Mitrovic 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: ---
[Issue 5140] Add __FUNCTION__ and __PRETTY_FUNCTION__
http://d.puremagic.com/issues/show_bug.cgi?id=5140 --- Comment #16 from bearophile_h...@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: ---
[Issue 5140] Add __FUNCTION__
http://d.puremagic.com/issues/show_bug.cgi?id=5140 --- Comment #15 from Andrej Mitrovic 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: ---
[Issue 5140] Add __FUNCTION__
http://d.puremagic.com/issues/show_bug.cgi?id=5140 --- Comment #14 from Rob T 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: ---
[Issue 5140] Add __FUNCTION__
http://d.puremagic.com/issues/show_bug.cgi?id=5140 --- Comment #13 from Jacob Carlborg 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: ---
[Issue 5140] Add __FUNCTION__
http://d.puremagic.com/issues/show_bug.cgi?id=5140 --- Comment #12 from Don 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: ---
[Issue 5140] Add __FUNCTION__
http://d.puremagic.com/issues/show_bug.cgi?id=5140 Jacob Carlborg changed: What|Removed |Added CC||d...@me.com --- Comment #11 from Jacob Carlborg 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: ---
[Issue 5140] Add __FUNCTION__
http://d.puremagic.com/issues/show_bug.cgi?id=5140 --- Comment #10 from bearophile_h...@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: ---
[Issue 5140] Add __FUNCTION__
http://d.puremagic.com/issues/show_bug.cgi?id=5140 --- Comment #9 from Jonathan M Davis 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: ---
[Issue 5140] Add __FUNCTION__
http://d.puremagic.com/issues/show_bug.cgi?id=5140 --- Comment #8 from bearophile_h...@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: ---
[Issue 5140] Add __FUNCTION__
http://d.puremagic.com/issues/show_bug.cgi?id=5140 --- Comment #7 from Jonathan M Davis 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: ---
[Issue 5140] Add __FUNCTION__
http://d.puremagic.com/issues/show_bug.cgi?id=5140 --- Comment #6 from Rob T 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: ---
[Issue 5140] Add __FUNCTION__
http://d.puremagic.com/issues/show_bug.cgi?id=5140 --- Comment #5 from bearophile_h...@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: ---
[Issue 5140] Add __FUNCTION__
http://d.puremagic.com/issues/show_bug.cgi?id=5140 Andrej Mitrovic changed: What|Removed |Added Keywords||pull CC||andrej.mitrov...@gmail.com Version|unspecified |D2 AssignedTo|nob...@puremagic.com|andrej.mitrov...@gmail.com OS/Version|Linux |All --- Comment #4 from Andrej Mitrovic 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: ---
[Issue 5140] Add __FUNCTION__
http://d.puremagic.com/issues/show_bug.cgi?id=5140 Rob T changed: What|Removed |Added CC||al...@ucora.com --- Comment #3 from Rob T 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: ---
[Issue 5140] Add __FUNCTION__
http://d.puremagic.com/issues/show_bug.cgi?id=5140 --- Comment #2 from bearophile_h...@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: ---
[Issue 5140] Add __FUNCTION__
http://d.puremagic.com/issues/show_bug.cgi?id=5140 bearophile_h...@eml.cc changed: What|Removed |Added CC||bearophile_h...@eml.cc --- Comment #1 from bearophile_h...@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: ---