I disagree. C++ already has this mechanism - the preprocessor it inherited from C. That one is a textual preprocessor step, and it's very important for the programmer to have this as a mental model - then they'll be able to use it in a smart way[0] and avoid dumb mistakes.
I'm not sure if this is the best model, but a good one for C++ templates is that they are tree-level code generators. Kind of like really dumbed down Lisp macros. They don't do textual substitution, but AST-level one. But they generate code nonetheless.
(I suppose exposure to Lisp and Lisp macros may be helpful here too - just to have a comparison with a system that's a proper compile-time AST-level code generator, and that with minimal syntax, you can actually write your code as AST directly and be as readable as syntaxful languages.)
--
[0] - I know the mainstream opinion in application-level C++ is to avoid using it at beyond includes, include guards, and occasional conditional compilation or third-party package configuration. There are good reasons to avoid it - beyond complexity, quite a lot of support tooling like IDEs get confused by more complex macros. But still, there are many instances where even the newest C++20 features won't help you reduce obvious mechanical boilerplate. I've learned to use the preprocessor in those cases - mostly for readability reasons.
I'm not sure if this is the best model, but a good one for C++ templates is that they are tree-level code generators. Kind of like really dumbed down Lisp macros. They don't do textual substitution, but AST-level one. But they generate code nonetheless.
(I suppose exposure to Lisp and Lisp macros may be helpful here too - just to have a comparison with a system that's a proper compile-time AST-level code generator, and that with minimal syntax, you can actually write your code as AST directly and be as readable as syntaxful languages.)
--
[0] - I know the mainstream opinion in application-level C++ is to avoid using it at beyond includes, include guards, and occasional conditional compilation or third-party package configuration. There are good reasons to avoid it - beyond complexity, quite a lot of support tooling like IDEs get confused by more complex macros. But still, there are many instances where even the newest C++20 features won't help you reduce obvious mechanical boilerplate. I've learned to use the preprocessor in those cases - mostly for readability reasons.