C++17-C++20：编译器能否优化递归拷贝/移动示例？

我要探讨的不是程序运行时的效率或性能分析，而是明确哪些表达式能在编译期被简化、理应被简化，或是有标准保证会被简化。这个话题相当复杂，和编译器优化级别紧密相关，就算是熟门熟路的开发者也得谨慎对待。我写了几个涉及拷贝/移动语义的示例，想确认自己的思路是否正确：

示例一：递归式nth函数 #

template<std::size_t I, class S, class... T>
decltype(auto) nth(S && s, T &&... t) noexcept {
    if constexpr(I == 0) return std::forward<S>(s);
    else return nth<I-1>(std::forward<T>(t)...);
}

调用nth<2>(w, x, y, z);的开销是否和直接调用std::forward<Y>(y)完全一致？

我的判断是肯定的：因为if constexpr是静态条件分支，编译期就会终止无效递归分支，最终递归链会直接落到返回std::forward的分支上——过程中每次只丢弃一个参数，尾部的冗余参数也会被直接忽略。我推测编译器完全能看透这类递归逻辑，尤其是它已经在编译期确定了返回类型，完全可以把整个递归调用简化成单个std::forward<Y>(y)操作，但不确定是不是高估了编译器的优化能力。

示例二：折叠表达式实现的last函数 #

template<class L, class... R>
decltype(auto) last(L && l, R &&... r) noexcept
  { return (std::forward<L>(l) ,..., std::forward<R>(r)); }

折叠表达式本质是模拟链式二元操作，这点让我有点顾虑。这里用的是逗号运算符，只会保留最后一个操作数的结果，那前面被丢弃的std::forward<L>(l)等操作会不会产生实际的求值开销？它们会经过链式展开后才被丢弃。我知道C++有递归实例化的限制，超出限制后编译器可能无法优化甚至编译失败，但想了解限制范围内函数的处理情况。

额外假设的验证 #

我还做了一个假设：递归的每一层只会实例化函数本身，其他上下文（比如将函数用于指针场景）不会影响优化逻辑，只有递归的端点才是关键——毕竟这些操作本质只是对引用的重命名。如果这个假设成立，仅指向函数名称的操作不会中断其他地方的冗余代码消除优化。

需要说明的是，这不是过早优化，也不是为了压榨透传函数的性能或重造std::get，而是出于对C++语言基础的夯实需求。

内容的提问来源于stack exchange，提问作者John P