std::forward_like并非C++23标准函数，而是对未采纳提案P2517R0的误传；C++23实际新增了std::move_only_function、更严格的std::format检查及[[assume]]属性，并放宽了属性语法位置。
std::forward_like 不是 C++23 标准中的东西，标准里没有这个函数。C++23 引入的是 std::forward_like 的“精神前身”——但实际叫 std::forward_like 的函数并不存在于任何已发布的标准草案或 ISO 文档中。
为什么搜不到 std::forward_like？
这是个常见误传，可能源于对 C++23 新增的 std::forward_like 相关提案（如 P2517R0）的误解。该提案确实讨论过类似语义的工具，但最终未被采纳为标准库组件。C++23 正式加入的是：
-
std::move_only_function（可移动、不可复制的函数包装器） - 更严格的
std::format安全性检查 -
[[assume]]属性 - 但没有
std::forward_like
C++23 真正支持的“属性转发语法”是什么？
这里指的其实是 [[...]] 属性在模板和转发上下文中的合法使用位置变化，而非新函数。C++23 允许在更多地方写属性，比如：
template<typename T>
auto wrapper(T&& x) [[nodiscard]] {
return std::forward<T>(x); // ✅ C++23 允许在函数定义上直接加属性
}
但这跟“转发类型信息”无关，只是语法位置放宽。真正的类型转发仍靠 std::forward<T> + 完美转发惯用法。
立即学习“C++免费学习笔记（深入）”；
如果真想模拟“forward\_like”行为，该怎么写？
所谓“forward\_like”，通常指：给定一个值 v 和一个目标类型 U，把 v 按照 U 的值类别（左值/右值）转发过去。这其实可以用 static_cast + 类型萃取组合实现：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
关键点在于：要从 U 推导出引用类别，再作用于 v 的值类别。
一个轻量、无依赖的实现如下：
template<typename U, typename T>
constexpr auto forward_like(T&& t) noexcept {
if constexpr (std::is_lvalue_reference_v<U>) {
return static_cast<std::add_lvalue_reference_t<std::remove_reference_t<U>>>(t);
} else {
return static_cast<U>(t);
}
}
使用示例：
int x = 42; auto&& r = forward_like<int&>(x); // → int& auto&& s = forward_like<int&&>(x); // → int&&
注意：
- 它不等价于
std::forward<U>(t)：后者要求U必须是模板参数推导出的“原始类型”，而forward_like允许任意U（比如const int&&） - 它不处理 cv 限定符自动传播，若需完整模拟，得加
std::remove_cvref_t和显式const处理 - 不能用于非完整类型，且对 volatile 修饰需额外分支
容易踩的坑：别把它当 std::forward 替代品
很多人试图用 forward_like<decltype(some_expr)>(x) 来替代 std::forward<T>(x)，这是危险的：
-
decltype(x)在 x 是变量时永远是左值引用，而std::forward<T>依赖模板参数T是否含&来决定转发方向 - 直接套
forward_like<decltype(x)>会强制变成左值转发，破坏完美转发语义 - 真正需要的是保持
T为模板形参，并用std::forward<T>—— 这才是标准且安全的做法
复杂点在于：值类别转发不是类型擦除，而是编译期契约。任何“模拟”都只是特定场景下的补丁，无法替代原始转发机制的设计意图。
