关于将 Linux 内核转换为支持现代 C++ 代码的前景，一个已有六年历史的 Linux 内核邮件列表讨论再次被点燃。现有的Linux 内核主要由 C 代码和各种手工编写的汇编语言构成，加上 Linux 内核支持 Rust 的工作也在不断增加。虽然目前还不清楚是否有足够的力量将其变为现实，但 Linux 内核社区邮件列表已重启讨论，探讨未来将 Linux 内核 C 代码转换为 C++ 的可能性。
早在 2018 年 4 月 1 日，红帽工程师大卫-豪威尔斯（David Howells）就提出了一组 45 个补丁，开始将内核转换为 C++。这将允许主线内核使用内联模板函数、内联重载函数、类继承以及其他目前 Linux 内核的 C 代码不支持的功能。那天很难进行认真的讨论，最终这些补丁在 Linux 内核邮件列表上停留了六年，没有引起太多讨论。
但昨天，长期从事 Linux 开发的彼得-安文（H. Peter Anvin）回应了内核邮件列表的主题。Anvin 写了一篇长长的 LKML 帖子，围绕为什么 Linux 内核的 C++ 最终可能是正确的时机提出了他的理由：
"安德鲁-平斯基（Andrew Pinski）最近知道了这个主题。我知道它是在 2018 年 4 月 1 日发布的，要么是个玩笑，要么可能被当成了玩笑。不过，我认为它有其合理性，我将在此尝试激发我的观点。"
自 1999 年以来，C 和 C++ 都有了长足的发展，而事实上，在我个人看来，C++ 终于"长大"了，对于操作系统内核所体现的嵌入式编程而言，它是一种更好的 C 语言。我是作为内核中大量宏和内联汇编Hacks的作者才这么说的。
让我这么说的真正原因是，我们最近提出的许多针对 gcc 扩展的要求，其实在标准 C++ 中很容易实现，而且在许多情况下，无需修改全局代码即可改进基础架构。
在我看来，C++14 是拥有合理元编程支持的"最低"版本，它拥有大部分元编程支持，却没有早期版本的类型地狱（C++11 拥有大部分元编程支持，但 C++14 填补了一些关键缺失）。
在我看来，C++20 才是真正改变游戏规则的主要因素；虽然早期版本可以使用大量 SFINAE hacks，但它们也提供了完全无用的错误信息。C++20 增加了一些概念，这使得真正获得合理的错误信息成为可能"。
对于那些可能会提出"用 Rust 重写 C 代码！"的人，Anvin 在他的信息中主动补充道：
"现在，为什么不使用 Rust 呢？首先，Rust 使用的是不同的语法（在我看来，往往是无端的），不仅所有内核开发人员都需要非常熟悉，才能获得与 C 相同的"感觉"，而且将 C 代码转换为 Rust 并不是一件可以零敲碎打的事情，而现有的 C 代码经过一些清理就可以编译为 C++。"
SUSE Lans 的 Jiri Slaby 表示支持 Linux 内核的 C++ 计划。最初发布内核补丁的红帽公司的 David Howells 也表示支持这一讨论。
我们将拭目以待 LKML 讨论的结果，以及在 2024+ 年是否最终有足够的动力支持现代 C++ 代码--或者至少是一些定义的 C++14~20 子集--在 Linux 内核中的应用。Linus Torvalds 过去一直热衷于反对 C++，但如果他对最近的 C++ 标准更加满意，或者他仍然坚持使用 C 语言来维护 Linux 内核，那么我们就能看到潮流是否最终转向了。
直到 2022 年，Linux 内核才开始从 C89 转向 C11。特别是如果达成共识，允许在内核中使用 C++14/C++20 编程子集，那么在提高基本编译器要求之前，可能还需要一段时间才能通过，以便推出更广泛的编译器支持。