關於將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 程式子集，那麼在提高基本編譯器要求之前，可能還需要一段時間才能通過，以便推出更廣泛的編譯器支援。