标签 泛型 下的文章

当 Go 还在追求极简时,C++ 26 却又加了四大“史诗级”新特性

本文永久链接 – https://tonybai.com/2026/03/31/go-minimalism-vs-cpp26-epic-new-features

大家好,我是Tony Bai。

在这个 Go、Zig 等“小而美”新语言颇受青睐的时代,如果你去技术社区里问一句:“C++ 这门语言怎么样?”

你大概率会得到一堆充满戏谑的回答:“太复杂了,别学”、“从入门到放弃”、“面试造火箭,工作拧螺丝”。

C++,这门诞生于上世纪 80 年代的编程语言,似乎早已被贴上了“老旧、臃肿、极其反人类”的标签。在很多新生代开发者眼里,它就像一头步履蹒跚的史前巨兽,理应被时代所淘汰。

但就在前天(2026年3月29日),这头“史前巨兽”不仅没有倒下,反而亮出了它那足以撕裂天空的獠牙。

C++ 标准委员会主席、C++ 界的“教父级”人物 Herb Sutter 亲自在博客上宣布:C++26 标准的技术工作,已正式完成!

Herb Sutter 还用极其兴奋的口吻将其定义为“自 C++11 以来最具冲击力的一次发布”。而这次更新的核心,是四个被他称为“Fab Four”(神奇四侠)的史诗级新特性。

当我耐着性子看完全部内容后,我脑子里只剩下四个字:叹为观止。

当 Go 语言的开发者还在为“是否要给语言增加一个三元表达式”,或泛型方法而激烈辩论时,C++ 却反其道而行之,给自己又加装了四门“宇宙级”的重型武器。这到底是 C++ 吹响的绝地反击号角,还是压垮骆驼的最后一根稻草?

今天,我们就来硬核扒开 C++26 这四大“金刚”,看看它们到底有多强,以及它们将如何影响将来程序员对编程语言的选择。

第一门重炮:反射(Reflection)——“代码生成代码”的终极魔法

Herb Sutter 将反射放在了四大特性之首,并称之为“自模板(Templates)发明以来 C++ 最重要的升级”。

什么是C++ 的反射?简单来说,就是让代码在编译期拥有了“自我审视”和“自我创造”的能力。

在 C++26 之前,如果你想实现一个通用的 JSON 序列/反序列化库,你必须写大量重复的模板代码,或者用各种丑陋的宏来“欺骗”编译器。

但在 C++26 中,你可以像这样写出充满“神性”的代码(代码示意):

这段代码,在编译的时候就能根据编译时的输入(test.json)自动分析JSON构造,并生成编译时用于计算的一个新类型。这在 Go 语言里,需要借助 reflect 包在运行时(Runtime)以牺牲性能为代价才能做到。而 C++,直接在静态编译期(Compile-time)零成本搞定了!

Herb Sutter 将其形容为“C++ 的十年火箭引擎”。这意味着,未来 C++ 社区将涌现出无数极其强大、但又极其复杂的元编程(Metaprogramming)库。C++ 的学习曲线,将再次被拉到一个新的高度。

第二道防线:内存安全(Memory Safety)——“只需重编,安全自来”

如果说反射让 C++ 的上限变得更加遥不可及,那么内存安全的提升,则是 C++ 在向 Go 和 Rust 的核心优势区发起的正面冲锋。

C++ 常年被诟病的核心痛点是什么?内存不安全。悬垂指针、未初始化变量读取(导致未定义行为)……这些噩梦困扰了 C++ 程序员几十年。

C++26 给出了一个极其诱人的承诺:你的老代码一行都不用改,只要用 C++26 模式重新编译,就能自动获得大幅度的安全提升!

这主要来源于两个方面的改进:

  1. 消灭未初始化变量的 UB:在 C++26 中,读取未初始化局部变量不再是“未定义行为(Undefined Behavior)”。这意味着困扰无数新手的、极其诡异的程序崩溃,将成为历史。
  2. “加固”的标准库:Google 和 Apple 已经将它们内部经过“加固(Hardened)”的标准库实现贡献给了 C++26。这意味着,当你使用 std::vector, std::string 等容器时,大量的边界检查会自动开启。

Herb Sutter 引用了 Google 的内部数据:

“仅在 Google,这项技术就已经修复了超过 1000 个 Bug,预计每年可以预防 1000 到 2000 个新 Bug 的产生,并将整个生产环境的段错误(Segfault)率降低了 30%。”

这简直是在对 Go 说:“你用 GC 换来的那点可怜的安全性,我 C++ 现在也能做到了,而且依然是零成本的!”

第三把利剑:契约(Contracts)——代码里的“法律条文”

如果你写过 Go,你一定对满屏的 if param == nil { return errors.New(…) } 感到厌烦。这种防御性编程,虽然有效,但极其啰嗦。

C++26 正式引入了语言级的契约编程

你可以像签合同一样,为你的函数制定严格的法律条文:

这些 pre 和 post 是编译器和运行时可以理解并强制执行的“法律”。如果调用者违反了前置条件,程序可以在开发阶段就立刻崩溃并给出明确的报错,而不是等到数据被污染后才在某个奇怪的地方爆炸。

虽然 Go 社区也在讨论类似的泛型断言,但 C++26 已经先行一步,将其做成了语言标准。

第四个引擎:std::execution——C++ 的“亲儿子”协程模型

在 C++20 中,虽然引入了 co_await 协程,但它只是一个语法糖,并没有提供一个统一的调度框架。

C++26 终于补上了这块短板,正式推出了 std::execution,也被称为 Sender/Receiver 模型

这是一个极其强大、统一的异步模型框架。它让你能以一种声明式的方式,去描述、组合和调度复杂的并发任务流。

下面是一段使用std::execution的代码示例:

// This is an example of a custom algorithm for starting work
// without allocations. This algorithm is also available in
// <exec/start_now.hpp>. (Users that don't write custom sender
// algorithms will not need to use receivers or call connect
// or start.)
template <stdexec::sender_in<stdexec::empty_env> Sender>
struct start_now {
  start_now(Sender sndr)
    : _op(stdexec::connect(std::move(sndr), _sink_rcvr())) {
    stdexec::start(_op);
  }
private:
  // start_now is implemented in terms of this custom receiver,
  // which is used to discard Sender's results.
  struct _sink_rcvr {
    using receiver_concept = stdexec::receiver_t;
    void set_value(auto&&...) noexcept {}
    void set_error(auto&&) noexcept {}
    void set_stopped() noexcept {}
  };
  stdexec::connect_result_t<Sender, _sink_rcvr> _op;
};

int main() {
  // A run loop is a fifo queue of work and a loop to execute the
  // work. It needs to be driven by calling its .run() member fn.
  stdexec::run_loop ctx;
  auto event_loop = ctx.get_scheduler();

  // Create two tasks that cooperatively multitask.
  auto task1 = stdexec::just()
             | stdexec::then([]{ std::puts("hello from task 1! suspending..."); })
             | stdexec::continue_on(event_loop) // suspend
             | exec::repeat_n(5)
             | stdexec::then([]{ std::puts("task 1 is done!"); });

  auto task2 = stdexec::just()
             | stdexec::then([]{ std::puts("hello from task 2! suspending..."); })
             | stdexec::continue_on(event_loop) // suspend
             | exec::repeat_n(8)
             | stdexec::then([]{ std::puts("task 2 is done!"); });

  // Start both tasks. This enqueues them for execution on the run loop.
  auto op1 = start_now(stdexec::start_on(event_loop, std::move(task1)));
  auto op2 = start_now(stdexec::start_on(event_loop, std::move(task2)));

  ctx.finish(); // tell the run loop to stop when the queue is empty
  ctx.run();    // tell the run loop to start executing work in the queue
}

这可以被看作是 C++ 对 Go 的 Goroutine + Channel 模型,以及 Rust 的 async/await + tokio 模型的终极回应。

它让 C++ 开发者第一次拥有了一套语言原生的、能够轻松编写“无数据竞争(Data-race-free by construction)”并发程序的“亲儿子”工具。

小结:一场没有退路的豪赌

反射、安全、契约、并发。C++26 的这四大金刚,每一个都足以在其他语言中引发一场大地震。

我们看到的是一头苏醒的巨兽。它没有选择像 Go 那样“断舍离”,也没有像 Rust 那样“偏执于安全”,而是极其贪婪地选择了:“我全都要!”

它既想要极致的表达能力和零成本抽象(反射、模板),又想要与 Rust 媲美的内存安全(加固标准库),还想要不输 Go 的并发表达力(std::execution)。

C++26 给老兵们提供了前所未有的强大武器,但也把本就陡峭的学习曲线,又向上抬升了一个令人惊叹的高度,宇宙第一复杂的编程语言,实至名归!

当 Go 的开发者还在为“是否要加个三元表达式”而争论不休时,C++ 已经头也不回地奔向了“万神殿”。

或许,编程语言的终局,真的不是“大一统”,而是“两极分化”:一极是像 Go 一样追求极致简单的“工程师语言”;而另一极,则是像 C++ 这样,专为那 1% 的、追求极致性能和控制力的“宗师级”开发者准备的、布满荆棘的封神之路。

C++26,欢迎来到神的世界,也欢迎来到神的炼狱。

参考资料

  • https://herbsutter.com/2026/03/29/c26-is-done-trip-report-march-2026-iso-c-standards-meeting-london-croydon-uk/
  • https://herbsutter.com/2025/06/21/trip-report-june-2025-iso-c-standards-meeting-sofia-bulgaria/
  • https://herbsutter.com/2024/07/02/trip-report-summer-iso-c-standards-meeting-st-louis-mo-usa/
  • https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p2996r13.html
  • https://www.youtube.com/watch?v=7z9NNrRDHQU
  • https://www.youtube.com/watch?v=oitYvDe4nps

今日互动探讨:

看完 C++26 的这四大“神仙”特性,你是感到兴奋,还是感到了深深的绝望?你觉得 C++ 的这种“大而全”的演进路线是对的,还是 Go 的“小而美”更代表未来?

欢迎在评论区分享你的看法!


还在为“复制粘贴喂AI”而烦恼?我的新专栏 AI原生开发工作流实战 将带你:

  • 告别低效,重塑开发范式
  • 驾驭AI Agent(Claude Code),实现工作流自动化
  • 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码,开启你的AI原生开发之旅。


你的Go技能,是否也卡在了“熟练”到“精通”的瓶颈期?

  • 想写出更地道、更健壮的Go代码,却总在细节上踩坑?
  • 渴望提升软件设计能力,驾驭复杂Go项目却缺乏章法?
  • 想打造生产级的Go服务,却在工程化实践中屡屡受挫?

继《Go语言第一课》后,我的《Go语言进阶课》终于在极客时间与大家见面了!

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造!30+讲硬核内容,带你夯实语法认知,提升设计思维,锻造工程实践能力,更有实战项目串讲。

目标只有一个:助你完成从“Go熟练工”到“Go专家”的蜕变! 现在就加入,让你的Go技能再上一个新台阶!


商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求,请扫描下方公众号二维码,与我私信联系。

Rust 看了流泪,AI 看了沉默:扒开 Go 泛型最让你抓狂的“残疾”类型推断

本文永久链接 – https://tonybai.com/2026/03/27/function-type-inference-should-work-in-all-assignment-contexts

大家好,我是Tony Bai。

在这个大模型(AI)写代码如喝水一般简单的时代,你有没有遇到过一种极其憋屈的场景:

你让 Claude Code 或者 Codex 帮你写了一段 Go 语言代码,逻辑清晰,结构优雅,连它自己都觉得这波操作满分。但当你满怀期待地按下 go run 时,Go 编译器却无情地丢给你一个红色报错:

cannot use generic function g without instantiation
(不能在未实例化的情况下使用泛型函数 g)

AI 沉默了,它不明白自己错在哪;如果你是个习惯了 Rust 那种“地表最强类型推断”的开发者,你可能会当场流下心酸的眼泪—— 在 Rust 里闭着眼睛都能推断出来的泛型参数,怎么到了 Go 里,它就突然变成了“残疾”?

如果你曾经被这个“诡异”的泛型报错折磨过,甚至因此怀疑过自己的智商,不要怪 AI 不懂 Go 语言。

因为就在最近,连“Go 语言之父之一” 的 Robert Griesemer 都亲自在官方 GitHub 上提了一个 Issue,承认这个语法限制不仅反直觉,甚至一度被认为是一个编译器 Bug!Griesemer 本人随即在 Issue 中自我更正,明确这需要语言规范(spec)层面的修改,而不只是修编译器。

今天,我们就来扒开这个在 Go 官方仓库引发热议的 Issue #77245,看看这个即将改变Go工程师日常编码的“底层规范级修补”,到底是怎么回事。

“薛定谔”式的类型推断

自从 Go 1.18 引入泛型以来,“不够聪明”的类型推断(Type Inference)就一直被开发者诟病。直到 Go 1.21 发布,官方宣称大幅增强了这部分能力:只要在赋值上下文中,目标类型是明确的,Go 就可以帮你自动推断出泛型函数的参数类型,不需要你手动写 g[int] 了。

这听起来很美好,对吧?

但现实是极其骨感的。我们来看看 Robert Griesemer 亲自给出的这个“薛定谔式的推断”的例子:

type S struct{ f func(int) }

func g[T any](T) {} // 这是一个简单的泛型函数

func _(s S) {
    s.f = g          // ✅ 没问题!Go 编译器智商在线,完美推断出 T 是 int

    s = S{f: g}      // ❌ 报错:不能在没有实例化的情况下使用泛型函数 g

    s = S{f: g[int]} // ✅ 没问题!必须手动写死 g[int]
}

看懂这个坑在哪里了吗?

当你写 s.f = g 的时候,编译器智商在线,它知道 s.f 需要一个 func(int),所以它机智地把泛型函数 g 实例化成了 g[int]。

但是(最气人的但是)!

当你使用结构体字面量 S{f: g} 进行初始化时,编译器却突然“智力下线”了。它死活推断不出 g 需要被实例化为 int,非逼着你极其啰嗦地写上 g[int]!

这种“一半聪明,一半智障”的表现,不仅存在于结构体里。在切片(Slice)、数组、Map,甚至是 Channel 的发送操作中:

type F func(int)
type A [10]F
type S []F
type M map[string]F
type C chan F

func g[T any](T) {}

func _() {
    var a A
    a[0] = g      // ok
    a = A{g}      // error: cannot use generic function g without instantiation
    a = A{g[int]} // ok

    var s S
    s[0] = g      // ok
    s = S{g}      // error: cannot use generic function g without instantiation
    s = S{g[int]} // ok

    var m M
    m["foo"] = g         // ok
    m = M{"foo": g}      // error: cannot use generic function g without instantiation
    m = M{"foo": g[int]} // ok

    var c C
    c <- g      // error: cannot use generic function g without instantiation
    c <- g[int] // ok
}

只要你使用了复合字面量(Composite Literals),这套“残疾”的类型推断就会集体失效。

为什么 Rust 和 AI 看了会沉默?

如果你去问一个 Rust 开发者:“目标结构体的字段类型 f func(int) 明明就摆在那里,Go 编译器为什么会看不见?”

Rust 开发者可能会拍着你的肩膀叹气。在 Rust 强大的类型推断系统面前,这种上下文推导简直是基本操作,根本不需要开发者操心。

而在如今 AI 辅助编程大行其道的时代,这个问题更加被无限放大。

大模型在学习了海量代码后,它的“直觉(Next-token prediction)”告诉它,这里上下文极其明确,根本不需要写死类型参数。于是 AI 开心地生成了 S{f: g},结果却被 Go 编译器无情打脸。你不得不停止思考,手动去把 AI 生成的代码一行行加上 [int]、[string]……

这根本不是 AI 的幻觉,而是 Go 语言规范(Spec)在当年设计时,由于过于严谨,给自己留下的思维盲区。

在最初的 Go Spec 中,关于泛型函数实例化生效的上下文规定得极其死板(只在某些直接赋值的场景生效)。当时的 Go 团队并没有抽象出一个统一的 “赋值上下文(Assignment Context)” 概念。这导致散落在各个角落的复合字面量操作,全都成了漏网之鱼。

官方的修补:一场牵一发而动全身的“规范手术”

起初,Robert Griesemer 以为这只是个单纯的编译器 Bug,只要改改代码就行了。

但随着讨论的深入,核心成员们(如 Austin Clements)发现,这事儿没那么简单。要从根本上解决这个问题,必须对 Go 语言规范(Spec)动刀子!

在随后的内部评审中,Go 团队做出了一个决策:

他们没有选择“头痛医头,脚痛医脚”地去给结构体、Map、切片分别打补丁。而是选择在 Go 语言最底层的定义——“可赋值性(Assignability)” 上做文章。

他们提出了一个新的 CL ,只要一个表达式符合“可赋值性”的校验(无论是等号赋值、结构体初始化、还是 Channel 发送),Go 编译器就必须启动泛型函数的自动类型推断。

这就好比给整个 Go 语言的类型推断系统,彻底打通了奇经八脉

小结

到这里,可能有开发者会问:“不就是少写几个 [int] 吗?至于这么大惊小怪吗?”

在几行代码的 Demo 里,这确实不是事。

但在大厂动辄十几万或几十万行的微服务源码中,当我们使用泛型去实现高阶的“工厂模式”、“回调注册”、“依赖注入”时,代码中会充斥着大量的结构体初始化和泛型函数传递。

如果没有统一的类型推断,原本极其优雅的代码,就会变成被各种中括号 [T, K, V] 塞满的“乱码”。

更少的手动类型标记,意味着更低的人类认知负荷(Cognitive Load),以及对 AI 代码生成工具更友好的兼容性。

Go 语言之所以能在一众花里胡哨的新语言中稳坐云原生霸主的交椅,靠的绝不仅是并发,更是这种对“代码清爽度”和“心智负担”极其克制、甚至有些偏执的追求。

好消息是,这个被开发者诟病已久的痛点,已经被 Go 官方提案评审委员会 “正式接受(Accepted)”

我们极有可能在即将到来的后续版本(比如Go 1.27)中,看到这段啰嗦的泛型代码彻底消失。

资料链接:

  • https://github.com/golang/go/issues/77245
  • https://go.dev/cl/751312

今日互动探讨:

在日常写 Go 泛型的时候,你还遇到过哪些让你觉得“Go 编译器简直是个智障”的奇葩场景?或者在对比 Rust/TS 时,你觉得 Go 的类型系统最需要补齐哪个短板?

欢迎在评论区疯狂吐槽与分享!


还在为“复制粘贴喂AI”而烦恼?我的新专栏 AI原生开发工作流实战 将带你:

  • 告别低效,重塑开发范式
  • 驾驭AI Agent(Claude Code),实现工作流自动化
  • 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码,开启你的AI原生开发之旅。


原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球,快来加入星球,开启你的技术跃迁之旅吧!

我们致力于打造一个高品质的 Go 语言深度学习AI 应用探索 平台。在这里,你将获得:

  • 体系化 Go 核心进阶内容: 深入「Go原理课」、「Go进阶课」、「Go避坑课」等独家深度专栏,夯实你的 Go 内功。
  • 前沿 Go+AI 实战赋能: 紧跟时代步伐,学习「Go+AI应用实战」、「Agent开发实战课」、「Agentic软件工程课」、「Claude Code开发工作流实战课」、「OpenClaw实战分享」等,掌握 AI 时代新技能。
  • 星主 Tony Bai 亲自答疑: 遇到难题?星主第一时间为你深度解析,扫清学习障碍。
  • 高活跃 Gopher 交流圈: 与众多优秀 Gopher 分享心得、讨论技术,碰撞思想火花。
  • 独家资源与内容首发: 技术文章、课程更新、精选资源,第一时间触达。

衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚,享受技术精进的快乐!欢迎你的加入!

img{512x368}


商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求,请扫描下方公众号二维码,与我私信联系。

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! Go语言第一课 Go语言进阶课 AI原生开发工作流实战 Go语言精进之路1 Go语言精进之路2 Go语言第一课 Go语言编程指南
商务合作请联系bigwhite.cn AT aliyun.com
这里是 Tony Bai的个人Blog,欢迎访问、订阅和留言! 订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠 ,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:

如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:

以太币:

如果您喜欢通过微信浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:
本站Powered by Digital Ocean VPS。
选择Digital Ocean VPS主机,即可获得10美元现金充值,可 免费使用两个月哟! 著名主机提供商Linode 10$优惠码:linode10,在 这里注册即可免费获 得。阿里云推荐码: 1WFZ0V立享9折!


View Tony Bai's profile on LinkedIn
DigitalOcean Referral Badge

文章

评论

  • 正在加载...

分类

标签

归档



View My Stats