TypeFunction example: ImplictConvTargets

[Adam D. Ruppe]

On Wednesday, 7 October 2020 at 11:58:35 UTC, claptrap wrote:
> Lets reverse the roles, say TF were invented first, and 
> somebody was arguing for templates to be added now. The TP 
> version would be a couple of stdlib calls and the template 
> version a whole page.

Templates actually enable all kinds of new things.

A type function cannot actually generate any new code nor create 
new types. Those are explicit limitations in the design right 
now, because by keeping them so strict it enables some 
optimizations that are... at best tricky with templates (many 
attempts to optimize templates end up causing compiler bug errors 
or, perhaps worse yet, random linker errors).

So supposed we lived in a world with only TF. You can make type 
lists and return basic type constants based on limited reflection 
over type (note that TFs will probably *not* support advanced 
`is` expression pattern matching as it is right now!)

Then someone comes along and says let's add templates. Templates 
can do everything a type function can do AND you can generate new 
code based on that information! No more awkwardly returning 
string literals and mixing them in at the usage point, the 
compiler will generate it all directly!

Oh there'd probably be pushback, I'd probably be arguing "but we 
can already mixin!" myself :) (though mixin sucks for name 
generation, you have to use __LINE__ or cookie string hacks, 
whereas templates automatically get unique names!)

But it'd also be a compelling new feature.

That's why I'd be a bit more excited about the type functions if 
they prove capable of doing things we can't really do right now, 
like transform function argument lists through tuple 
manipulation. That'd be a cool application of the same general 
principle of reordering alias[] entities.