Get variable symbol name that was passed to a paramater?

[Timothee Cour]

can your 'inspect' method handle:
* multiple arguments?
* expressions?

I wrote a function that does both, it's one of those things that are very
useful for quick debugging:

import util.prettyprint;
void main(){
  int x=23;
  double y=2.4;
  writelnL(x,y,x*y);
}

//output:
file test.d:7 {
  x=int{23},
  y=double{2.4},
  x*y=double{55.2},
}

-----
The way it works:
void writelnL(string file=__FILE__, Line_t line=__LINE__, T...)(T args){
...
auto argNames=getArgNamesFromFile(file,line);
...
}

This reads at runtime file/line and caches the information with memoize to
avoid re-reading the same file/line multiple times. I had also tried
reading the file/line at compile time using import(file)[line] but that
resulted in massive compile time slow-downs even when the actual writelnL
wasn't used at runtime. Then the code parses the line to extract each
argument names using a simplified D grammar.

However this still has some runtime penalty (reading a whole file just for
1 line) and is doing more work than necessary, as compiler has access to
this info.
I've already asked for this in the past (see email: "feature request:
__ARGS__ for logging (cf __FILE__, __LINE__, __FUNC___):

but Jacob pointed out that AST macros would make this un-necessary (like
wise with another proposal I made "proposal: a new string litteral to embed
variables in a string" ):

"I don't think that __ARGS__ is a bad idea, I just think that there are
several features in D which could be replaced with a library solution using
AST macros (if those were available)"

So let's either get a roadmap for introducing AST macros (preferred) or
let's allow this very simple __ARGS__ in the language.



On Sat, Nov 9, 2013 at 11:05 AM, Rob T <alanb at ucora.com> wrote:

> On Saturday, 9 November 2013 at 11:07:08 UTC, Dicebot wrote:
>
>> On Saturday, 9 November 2013 at 09:12:21 UTC, Rob T wrote:
>>
>>> It works except when passing a variable contained inside a struct or
>>> class due to a missing "this" during evaluation, I'm also worried about
>>> template bloat.
>>>
>>> I figure mixins may help, but not if it's same or less convenient to use
>>> as the double entry method.
>>>
>>> Any suggestions, or is it just impossible or not worth trying?
>>>
>>
>> I have not found good workaround for this so far and consider it a main
>> use case for template alias parameter enhancement.
>>
>
> Do you know if there's already a enhancement request posted for this? I'll
> make one if not.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d-learn/attachments/20131109/4bd7bdaf/attachment.html>