一位大神在2018年对C/C＋未来十年的预测，3年了，实现了多少？

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）。我希望（当然也希望如此）在接下来的这一年中看到这一方面的显着改善