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

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

为什么 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(); }
    };
};