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