I agree with the author on many things - parameter packs however.. I've looked at them several times. Even if you get a grasp on their syntax, I've almost never been in a situation where they could be used. As he correctly observes it's a compile time thing.
> In my particular scenario, all the texture file paths are hardcoded
That feels like a very unique case. Usually data is given in a vector or something and then you're out of luck anyways. Plus the syntax is very unintuitive (think about your colleagues), debuggability is zero.
Also the argument about constness feels a bit contrived. Sure with this you can write const and feel good, but the other version is hardly a bad nonconst. You can wrap things in functions or whatnot. The function seems to be a bit long anyways.
Parameter packs are quintessential compile time lists: you can pass them around, transform them, destructure them…they are really quite useful when you need to make sure certain things are done at compile time. For example, I recently used them heavily to generate code at compile time for a virtual machine I designed, all from a single instruction architecture that I encoded in the type system.
> Even if you get a grasp on their syntax, I've almost never been in a situation where they could be used.
Parameter packs can make some ugly code substantially simpler, IMHO. For example, I contributed some changes to the Godot C++ bindings a couple of years ago that made a number of super common functions variadic instead of having to create and pass in collections (eg debug printing, specifying argument types when registering signals, stuff like that). While not a strictly necessary change, it makes the resulting code easier to read. Parameter packs allow this.
Variadic templates are essential for simple, argument forwarding template functions. std::vector::emplace_back is a very simple example, this kind of use comes up now and then during work.
edit: This also shows that you don't have to be able to write variadic templates to reap the benefits of it. You can enjoy the benefits while using a library that uses it.
The key to understanding techniques based on templates is to realize that C++ templates are just another programming language that (a) is functional, (b) is interpreted at compile time, and (c) where values are C++ types.
> In my particular scenario, all the texture file paths are hardcoded
That feels like a very unique case. Usually data is given in a vector or something and then you're out of luck anyways. Plus the syntax is very unintuitive (think about your colleagues), debuggability is zero.
Also the argument about constness feels a bit contrived. Sure with this you can write const and feel good, but the other version is hardly a bad nonconst. You can wrap things in functions or whatnot. The function seems to be a bit long anyways.