www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Templates and expressions

reply renoX <renosky free.fr> writes:
Hello,

I've made a template to have a better (in my mind) format for printing, 
so like writef the template take a tuple of argument as a parameter, it 
works well when the parameter are variable but my problem is that if an 
argument of the template is an expression, there is a compilation time 
failure..

Ie putf!(x+y) fails to compile..

If I change the prototype to wrap everything in a string, the problem 
now is that as everything is a string I loose access to the type of the 
parameters, which I use..

Is-there a way to solve this problem?

Meta-programming in D will stay quite limited if you're obliged to wrap 
every expression in a string IMHO..

renoX
Feb 25 2007
parent Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
renoX wrote:
 Hello,
 
 I've made a template to have a better (in my mind) format for printing, 
 so like writef the template take a tuple of argument as a parameter, it 
 works well when the parameter are variable but my problem is that if an 
 argument of the template is an expression, there is a compilation time 
 failure..
 
 Ie putf!(x+y) fails to compile..

And it always will as long as (x+y) is not a compile-time constant, which is (at least) as long as x and/or y is itself not a compile-time constant.
 If I change the prototype to wrap everything in a string, the problem 
 now is that as everything is a string I loose access to the type of the 
 parameters, which I use..
 
 Is-there a way to solve this problem?

typeof(mixin("x+y")) ? Or, if it's an option in your implementation, you could generate code that passes the arguments as parameters to a template function, using IFTI to get at the types.
 Meta-programming in D will stay quite limited if you're obliged to wrap 
 every expression in a string IMHO..

Only expressions that aren't compile-time constants need to be wrapped in a string (and ones whose type is not a valid template parameter type). Walter[1] has been talking about passing expressions as alias parameters or something like that, so maybe this will change. [1]: and/or Andrei
Feb 25 2007