most non-function templates could be advantageously replaced by function templates

Jonathan M Davis jmdavisProg at gmx.com
Tue May 14 14:06:30 PDT 2013


On Tuesday, May 14, 2013 10:27:38 Dicebot wrote:
> On Tuesday, 14 May 2013 at 06:56:23 UTC, Timothee Cour wrote:
> > ...
> 
> My conclusion as well. Currently I follow simple rule when doing
> meta-programming in D:
> * If stuff returns type, make it a template and write in
> functional recursive flavor
> * If stuff returns data, make it a function (template
> function if needed) and just let CTFE do the magic.
> 
> One major advantage is that it helps to reduce template instance
> count and thus compiler memory consumption.

I believe that the typical approach at this point is that if it's something 
that will only ever be done at compile time and/or is querying about a type, 
an eponymous template is used, whereas if it's something that might be useful 
at runtime, then a normal function is used which is then CTFEable.

I've never really thought about making the type stuff into functions, but I 
don't really agree that it's a problem that they aren't, particularly since it 
makes no sense to use them at runtime, and at least with eponymous templates, 
even if you try and use them at runtime, the result is still calculated at 
compile time, unlike with CTFE. I'm not sure that it actually matters much, 
but that _would_ result in a slight performance penalty for any code that was 
using traits in runtime code for some reason (though again, I don't know why 
you would), and as Steven pointed out, CTFE carries a definite performance 
penalty at compile time at the moment (though hopefully that's temporary).

My gut reaction is definitely to keep doing traits as we have been, and it does 
seem off to me to make it so that something that's purely meant for compile 
time can be used at runtime, but it may make sense to change them.

- Jonathan M Davis


More information about the Digitalmars-d mailing list