"temporary" templates

H. S. Teoh hsteoh at quickfur.ath.cx
Wed Nov 27 18:11:37 UTC 2019


On Wed, Nov 27, 2019 at 11:32:13AM -0500, Steven Schveighoffer via Digitalmars-d wrote:
[...]
> The more I think about it, the more I like the CTFE with Types as
> first class approach, because then I can use actual mutating code vs.
> immutable functional approach that is required with templates.
[...]

I've been following this thread, and am coming to the same conclusion
too.

While templates are expressive enough to encode complex computations,
they aren't exactly the most conducive to such, and in terms of code gen
they aren't really the best tool for the job. Strictly speaking
templates really should be about manipulating the AST; using them to
perform computations is possible but a poor choice of tool IMO.

CTFE with first class types is much better because then it becomes
obvious that this is for *computation*, and the compiler knows that it's
intended to be computation rather than AST manipulation, so it can
optimize accordingly (discard intermediate results, etc.). No need for
additional annotations on templates or other such additional
complexities.

And since we can already use CTFE results in template arguments, this is
not a loss to expressiveness. We just re-encode what we currently use
templates for into CTFE form, let the CTFE engine perform whatever
arbitrary computations we want on it, then return the result as a
template argument list that can be used to transform the AST as
previously intended.

We then have the nice paradigm:

	Computations -> CTFE
	AST transformations -> templates

and we can get rid of ugly recursive templates like staticMap, and
replace it with a much nicer CTFE implementation, or even outright just
drop staticMap and replace it with std.algorithm.map taking an alias
list as argument, thus staying DRY.


T

-- 
Recently, our IT department hired a bug-fix engineer. He used to work for Volkswagen.


More information about the Digitalmars-d mailing list