"temporary" templates

[Suleyman]

On Wednesday, 27 November 2019 at 18:11:37 UTC, H. S. Teoh wrote:
> On Wed, Nov 27, 2019 at 11:32:13AM -0500, Steven Schveighoffer 
> via Digitalmars-d wrote: [...]
>> [...]
> [...]
>
> 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

Perhaps this is the opportunity to make a good runtime reflection 
system. We have typeid() for types, for an alias sequence which 
contains only types an no declarations we can implement 
NoDuplicates as a function that takes a TypeInfo[] and return the 
array with no duplicates in it, but we need a way to get a 
compile-time type from a TypeInfo, sort of a reversed typeid().