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

c++oding="utf-8" ?>

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

c++26的sender/receiver模型将如何重塑异步编程？ (p2300 std::execution)

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 会导致标准与现实脱钩，损害可信度

那现在该用什么？

当前可行路径非常明确：

Git Pro

Git高级操作：smart-commit、rebase、bisect、worktree、reflog、冲突解决、子模块、PR流程

下载

协程仍是首选：用 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）
关键信号：ISO C++ 官方 GitHub 仓库中，std::execution 模块已从 C++26 tracking issue 中移除，归档至 “Deferred” 标签

// 当前最接近“标准 sender”风格的合法写法（C++23，无需 P2300）
#include <coroutine>
#include <future>

template<typename t>
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(); }
    };
};
</typename></future></coroutine>

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