为何GSL的finally函数需const&特化？仅用万能引用是否可行？

一、为什么需要const&版本的重载？ #

这个设计核心是为了区分左值与右值的处理逻辑，同时避免悬空引用的风险：

• 当你传递一个命名的、const的左值函数对象（比如一个const lambda、或者存储在const变量里的函数器）时，const&版本会将函数对象拷贝一份到final_action中。这样final_action持有独立的副本，完全不受原对象生命周期的影响——哪怕原对象在finally触发前被销毁，副本依然能正常执行动作，这正是ScopeGuard最核心的安全需求。
• 如果只有万能引用版本，当传递const左值时，模板推导会将F推导为const T&（T是函数对象类型），此时final_action<F>会持有原对象的引用。一旦原对象提前销毁（比如离开其作用域），finally执行时就会调用一个已失效的对象，导致未定义行为。

除此之外，这个重载还能让代码的意图更清晰：左值走拷贝，右值走移动，分工明确，避免模板推导带来的隐式行为混淆。

二、仅保留万能引用版本能实现相同功能吗？ #

答案是不能，主要问题出在左值处理上：

• 对于左值（包括const左值），万能引用版本会推导为引用类型，final_action将持有原对象的引用。如果原对象的生命周期短于finally的作用域（比如原对象是一个局部变量，在finally触发前就被销毁），就会出现悬空引用，导致执行动作时出现未定义行为。
• 虽然你可以手动通过std::ref或std::cref来控制是否持有引用，但GSL的设计目标是提供安全、易用的默认行为——const&版本默认用拷贝保证安全性，而万能引用版本则负责高效处理右值（通过std::forward移动而非拷贝，减少性能开销）。

举个简单的例子对比：

// 情况1：使用const&版本
const auto cleanup = [](){ std::cout << "cleanup done\n"; };
{
    auto guard = finally(cleanup); // guard持有cleanup的副本
} // guard销毁，执行副本的cleanup，正常输出

// 情况2：只有万能引用版本
const auto cleanup = [](){ std::cout << "cleanup done\n"; };
{
    auto guard = finally(cleanup); // guard持有cleanup的引用
} // 这里如果cleanup在guard销毁前已经失效（比如外层作用域结束），就会出问题

当然，如果你在使用时始终确保左值的生命周期覆盖finally的作用域，似乎能正常工作，但这违背了ScopeGuard“无需手动管理生命周期”的设计初衷，引入了潜在的安全隐患。

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