D's treatment of values versus side-effect free nullary functions

[Jonathan M Davis]

On Tuesday, July 20, 2010 17:24:33 bearophile wrote:
> Jonathan M Davis:
> > But theoretically, it
> > could be used for optimizations just like inlining (particularly with
> > pure functions), and that being the case, it probably will at some
> > point.
> 
> Pure functions go well with CTFE because they don't use global state, but
> you can run code at compile time only if all the arguments are known at
> compile time :-)
> 
> If some of their arguments are known at compile time and some of them are
> not known, and you want to optimize better, then you need partial
> compilation, that is a bit hard to implement, probably makes the compiler
> slow and complex.
> 
> So for a practical form of manual partial compilation practical time ago I
> have proposed something similar to GCC __builtin_constant_p
> (http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Other-Builtins.html#index-g_t
> _005f_005fbuiltin_005fconstant_005fp-2392 ), that is syntax sugar that you
> can use inside functions to turn them into templates (I don't know if you
> can also have a single entry point to keep the possibility of taking their
> address). You can use a static if with such __trait(isCTAgument, foo), to
> tell if each function argument as foo is known at compile time, and do
> something with it if it is. This is like defining those arguments as CT
> template arguments, that later the optimizer can optimize better (and
> perform the partial compilation).
> 
> Bye,
> bearophile

Partial compilation would indeed be a big step forward, but it would certainly 
be a lot of work. Just being able to have functions run with CTFE which could be 
fully run with CTFE would lead to some nice optimizations. Certainly, that would 
need to be achieved before we could look at having partial compilation. Still, 
partial compilation would certainly be cool if we ever reached that point.

- Jonathan M Davis