You misunderstand why the C++ version is complex.

Here's a similar version in C++ that is a one liner too.

https://godbolt.org/z/dhsdoGcc4

Notably, examine the simple assembly generated. In comparison, most other languages doing this will not be able to optimize away these abstractions at all.

I understand just fine why the C++ version is complex: it's because C++ is a poor language for higher-order function abstractions. Please don't make excuses for C++'s excessive inessential complexity: there is no reason why a programmer should need to concern themselves with "const r-values" and similar shenanigans in order to accomplish this simple task.

The fact that the compiler is able to optimize away this code is a compiler issue, not a language issue. ghc will optimize away Haskell's flip and I didn't once have to write a compile-time index-reverser in template code.

> there is no reason why a programmer should need to concern themselves

Agreed, hence my one liner version.

> ghc will optimize away Haskell's flip

Can you show me how? I am seeing 5000 lines of assembly.

https://godbolt.org/z/KqTq5Ez5n

The assembly is hard to understand. I recommend looking at the C-- intermediate output, using the -ddump-cmm flag, with -O2. The results in most of the functions getting inlined and flip is removed entirely.

You can see this clearly if you use conspicuous numbers. If, instead of (flip foo 2 3), you give (flip foo 2 99), you will code like this:

           R3 = GHC.Types.[]_closure+1;
           R2 = 97;
           Sp = Sp - 16;
           call GHC.Show.$fShow(,)_itos'_info(R3,
                                              R2) args: 24, res: 0, upd: 24;

97 is calculated at compile time.