c++26的Sender/Receiver模型将如何重塑异步编程？ (P2300 std::execution)

c++kquote>c++26 不包含 std::execution（P2300），该提案已在 2024 年 Kona 会议被 WG21 正式否决；主因是范围失控与实现脱节，主流标准库尚无符合语义的运行时支持。

C++26 的 std::execution（P2300）**不会落地**——它已被 WG21 在 2024 年 2 月的 Kona 会议上正式否决，**不会成为 C++26 的一部分**。 这意味着：你不需要为“C++26 的 Sender/Receiver 模型”做任何迁移准备，它目前不存在于标准时间线中。

为什么 P2300 被拒绝？

核心问题不是技术不成熟，而是“范围失控 + 实现脱节”：

• sender/receiver 原本想统一异步操作（如 std::async、协程 awaitables、网络 I/O），但最终提案膨胀到必须重定义执行器（executor）、调度语义、错误传播、取消机制，甚至影响 std::Thread 和 std::jthread 的抽象层
• 主流实现（libstdc++、libc++）明确表示：没有可交付的、符合 P2300 语义的运行时支持；LLVM 和 GCC 团队也未承诺在 C++26 周期内完成实验性实现
• 委员会判断：强行塞入 C++26 会导致标准与现实脱钩，损害可信度

那现在该用什么？

当前可行路径非常明确：

• 协程仍是首选：用 co_await + 自定义 awaiter 封装任意异步源（如 libuv、asio、winRT），稳定、可调试、编译期检查强
• 第三方库继续主导：boost::asio（v1.83+ 已深度集成 sender/receiver-like 语义，但不依赖 P2300）、facebook/folly、microsoft/cppwinrt 都提供生产级异步原语
• 标准库仅提供基础构件：C++20 的 std::jthread、std::latch/std::semaphore、C++23 的 std::stacktrace 和改进的 std::format，用于辅助而非驱动异步流

Sender/Receiver 还有未来吗？

有，但路径已重置：

• P2300 被拆解为多个更小的 TS（Technical Specification）草案，例如：
  • P2955（std::task 简化协程包装）
  • P2976（轻量级 sender 概念，不绑定执行器）
  • P3174（取消语义标准化，独立于 sender）

这些新提案将单独评审，最早可能进入 C++29 或更晚的 TS，且每个都要求已有两个以上可互操作的实现

• 关键信号：ISO C++ 官方 gitHub 仓库中，std::execution 模块已从 C++26 tracking issue 中移除，归档至 “Deferred” 标签

// 当前最接近“标准 sender”风格的合法写法（C++23，无需 P2300） #include  #include   template struct task {     struct promise_type {         T value_;         std::exception_ptr ex_;         auto get_return_object() { return task{}; }         auto initial_suspend() { return std::suspend_always{}; }         auto final_suspend() noexcept { return std::suspend_always{}; }         void return_value(T v) { value_ = std::move(v); }         void unhandled_exception() { ex_ = std::current_exception(); }     }; };

真正要警惕的，不是“怎么用 sender”，而是误信某些博客或会议幻灯片里“C++26 已包含 P2300”的过时信息——标准进程是公开、缓慢、高度保守的，所有变更都能在 cplusplus/papers 里查到原始记录。