But don't forget that it also doesn't compose as well as the other options.

I don't think it's true. Show some example?

Templates work even in betterC mode.

Can you template a template?

I believe so; see the entire meta package in the standard library: https://dlang.org/phobos/std_meta.html

Usually when something is called "meta" it means that it is special and does not compose.

I had someone explaining D templates to me on an Idris meetup, but it's been a few years, so I might very well be wrong here and not remember correctly. I'm happy to be corrected.

My next question would be: can I write those meta templates myself and modify them with themselves? In the same way that I could have a type-level function that applies another type-level function twice and then apply it on itself to get a new type-level function that applies another type-level function four times.

Do you mean does recursion work? Absolutely!

I wasn't talking about recursion but composition. Can I write template A and then apply it to itself to get template B and then apply that onto template C to get template D.

Yes.

I can't quite wrap my head around how that would work, but I'll trust you and then take my original claim back!

auto alist = [1, 3, 2];

alist .sort .map!(x => x * x) .map!(x => x - x/2) .map!(x => x + 1);

This seems like what you're asking. Each of those is a template. And while this is all logic code, D has inferred the type aka: SortedRange!Map!Map!Map

With some details removed.

I don't see that as true.

But are templates guaranteed to compile without errors for any arguments that match the constraints? If not, then D is in the same situation as C++ with concepts: there is always the possibility of having to debug errors from the template implementation because the authors didn’t choose precise enough constraints. Rust, Go, Haskell, etc. do guarantee successful compilation, though at the cost of making their generics systems far less suitable for metaprogramming.

Unfortunately C++20 only gave us concepts light, however Circle might be getting full concepts as they were originally designed, and those are like Rust, Go, Haskell, etc.

There's a core contingent of ISO members who don't like (don't understand?) `concept_map`; without late (and layered) binding of types to concepts you're really just rolling out a template prediction scheme.

I mainly use C++ on side projects and native library bindings, somehow I think ISO will need to change their ways if they want people to still care about anything past ISO C++23 for green field projects.

> there is always the possibility of having to debug errors from the template implementation because the authors didn’t choose precise enough constraints

That is indeed possible, but it's hard to see why that is a problem. Any problems would show up at compile time, and fixing errors flagged by the compiler is pretty routine programming work.