feature request: __ARGS__ for logging (cf __FILE__, __LINE__, __FUNC___)

[timotheecour]

One of the rare features I miss in C/C++ is stringification macro 
using "#x":

---
#include ...
#define DEBUG(x) disp_val(#x,x)
template<typename T>
void disp_val(const char*name, const T& x) {std::cout << name << 
"=" << x;}
int main(){
DEBUG(1+2); //will print 1+2=3 (and we can add line, file and 
func info)
ASSERT(1+2==4); //can also be defined such that it'll print 
1+2==4 failed...
}
---

In D, we have built-in assert message that'll print the failing 
expression "1+2==4 failed" in case of failure but that's about 
it: no further processing can be done on that message, and 
there's nothing we can do about the DEBUG(1+2) case. I did a 
function that requires one to write mixin(myDebug("1+2")); but 
that's not as good, especially because of the quoting that makes 
most IDE's unaware of the syntax inside (maybe monod would work 
but still...).

However there could be a clean D solution that alleviates need 
for macros:
I'd like to add __ARGS__ to the list of __FILE__, __LINE__, 
__FUNC___:

P1) 1st proposal:
__ARGS__ is a string representing the comma separated list of 
arguments passed:
void DEBUG(T,A)(T a, A args=__ARGS__){writeln(args,"=",a);}
void DEBUG2(T1,T2,A)(T1 a1,T2 a2, A args=__ARGS__){writeln(args);}
DEBUG(1+ 2); //will print "1+ 2=3", ie args="1+ 2"
DEBUG(1+ 2,
3*3);
//will print "1+ 2,3*3" (ie normalize the comma separation)

P2) same but __ARGS__ is string[] with one string per argument; 
the compiler already did the job of parsing, might as well use it:

void DEBUG(T)(T a1, T a2, string[] args=__ARGS__){
writeln(args[0],"=",a1);
writeln(args[1],"=",a2);
}

A question: whether or not to include the first argument in a 
UFCS/member function call ("hello".fun(1+2) ).

P3)
additionally, create a __CONTEXT__ that is a struct consisting of 
__ARGS__,__FILE__, __LINE__, __FUNC___. This has been proposed 
before and makes even more sense now. Additionally, it could give 
info on whether the call was UFCS'd or not, etc, information 
which is lost otherwise (I don't think traits could help 
distinguish which version was called, a.fun(b) or fun(a,b)).