C

當前針對C提出的一些更改基本上是已經新增到C ++的功能的後向移植。例如，有一組論文建議將C ++屬性（例如［［nodiscard］］和［［fallthrough］］）新增到C，並對已經在C ++中的特定屬性進行標準化。

已提出對C標準庫的許多新新增，以使其與IEEE 754 / ISO 60559標準的最新新增保持一致。

總是有一些建議，例如更好的措辭以澄清意圖，消除可能的歧義，消除矛盾等等。其中一些可能至少在某種程度上改變了標準的含義，例如，試圖“澄清”“未定義的行為”的含義，並且在此過程中還可能會改變其對實現的限制。

我猜想浮點數的新增將被批准（以某種形式）。新增屬性尚不確定，但是我想它們也有相當不錯的機會。考慮到它的重要性，我想可能還會有一些關於並行程式設計支援的內容，但是它們可能採用的形式似乎不確定。

C ++

我想說C ++的可預測性要比C小。有很多建議，其中一些更可能對語言進行根本性的改變。與針對C提出的許多更改相比，這些更改中的許多也更具爭議性。

C ++ 20

儘管如此，更改仍需要時間。我們已經對C ++ 20中可能存在的內容有了非常明確的認識。有許多報告，涵蓋了聖地亞哥C ++會議上批准（或未批准）的內容。

因此，我們已經知道C ++ 20可能會使用的大多數內容。在幾乎完全完成C ++ 20之前，基本上只需要再召開一次會議。因此，C ++ 20（最終）將具有某種形式的概念，並且將具有範圍。許多人希望看到的其他重要功能之一是對協程的支援。現在已經對此進行了多次討論和投票。尚無將其合併到標準中的共識。我認為可以將其轉化為C ++ 20的可能性約為20-30％。

C ++ 23：

如果協程不包含在C ++ 20中，我想它們很有可能會出現在C ++ 23中。多數反對當前提案的人總體上並不反對協同程式的基本思想，而只是反對他們在當前提案中採用的形式。其他選票則基於更多的程式性理由，希望有更多時間閱讀和評估某些論文（尤其是在母語不是英語的人們中尤其普遍）。

我認為在C + 23中可能還會有另外兩個附加功能：執行程式和網路連線。已有一段時間的網路技術支援，但有相當多的新草案將執行者重寫。我希望在C ++ 23中都能看到它們。

C ++ 26：

首先要附帶條件：特別是如果對特定領域的興趣增加，這裡提到的幾乎所有內容都可能會及時完成，以包含在C ++ 23中。

透過檢視已釋出的各種TS文件，可以找到其他可能的補充內容。 C ++ 17和C ++ 20的一些實質性內容以前曾作為TSes釋出，我希望這種情況會繼續下去。儘管它們不如網路和執行器那樣完善和完善，但它們還是模組和/或併發，反射，事務性儲存器和圖形之類的技術支援和/或技術支援建議的草案。

在這些模組中，我希望至少在模組，併發/並行和反射方面會有所採用。我猜想採用與事務性記憶體或圖形相關的東西不會令我特別驚訝，但至少目前我對這兩種驅動力都不抱有太大希望。

在C ++中尋求創新的另一個重要地方是Boost。許多TS都來自Boost庫，而且很可能還會繼續。舉例來說，我可以想象基於Boost Beast的東西將被接受為TS，並及時合併到C ++ 26的標準草案中。

非標

還有很多事情（或多或少）與標準化無關。我看到的最大的願望就是更好地管理庫。 C ++的主要目標之一是支援編寫好的庫，而作為一種語言，它在這方面做得很好。

不幸的是，開發生態系統的匹配度不是特別好。透過使用某種廣泛使用的軟體包管理系統（例如pip，RubyGems，Cargo），大多數其他語言比C ++更加容易將庫包含到專案中。

許多人已經注意到了這一點，並正在為解決該問題而採取各種解決方案（例如，vcpkg，conan。io）。我希望（當然也希望如此）在接下來的這一年中看到這一方面的顯著改善