可能是goto/setjmp的伤害性更大所以
【 在 speedboy2998 的大作中提到: 】
: 污染性太强了。。。
: 老老实实地判断返回值不好好的吗？
--
FROM 221.198.65.*

不是这个，是以这个为基础的类似rust的语法
```c++
auto a = f()??;

// ...
```
如果f()返回std::expected为False，就不执行接下来的逻辑立刻返回，否则就用来构造a
【 在 milksea 的大作中提到: 】
: 已经引入标准了，std::expected。但标准库api没有都搞两套。
--
FROM 114.251.196.*

所以是不是我学会了新版 c++ 就等于学会了 rust?

【 在 milksea 的大作中提到: 】
: 提案估计在路上。不过实话说这个语法糖的重要性真不如标准库以此为基准大改造，后者更难。
--
FROM 110.84.123.*

这事我思考了一段时间，为啥现在对象的所有权会变得这么复杂呢。一个很重要的原因就是有大量回调函数的存在，让对象的生命周期跳出函数的生命周期。

原本 RAII 或者简单引用计数就能够做好资源管理，现在因为有大量的异步回调，变得不够用了。所以新兴的 rust 这些语言才会搞出这么复杂的资源管理模型。

看人家 golang 就不会那么麻烦。c# 也有值类型，也不会那么麻烦。

依我看，等 c++ 也普及了协程编程之后，rust 就会变得一文不值。

【 在 milksea 的大作中提到: 】
: 还是有点差别。
: safe c++的提案（safecpp dot org）倒是特别高仿复刻rust，关键的borrow checker，默认mut，pattern match什么的都有。
: 我觉得rust对c++熟手不难学，它安全性上强调的几个点，比如所有权和生存期，在传统面向对象领域其实是交给程序员自己思考的；在语法表达上的变化，熟悉现代c++和一些函数式风格的话也没啥。
: ...................
--
FROM 110.84.123.*

如果有协程，很多并发访问就能被避免。

实际 golang 和 c# 的协程我觉得也不够优秀。原因是 golang, c# 和 java 都选择了让协程在线程自由调度，因为他们有庞大的兼容性包袱需要继承。

下一门语言我希望是单线程多协程 + 进程隔离式的架构。那么既然是单线程，所谓的并发性安全问题就几乎不再存在了。搭配 cow 技术即可解决掉现在各种编程语言的困境。

现在编程语言把操作系统的线程 API 以及 CPU 核并行计算这种概念直接暴露给程序员，我觉得相当不妥的。而且可扩展性也不够强。应该换个思考方式：

1. 程序员获得一个单一的 CPU 核心、一块独立的无限的内存空间。
2. 程序员编写模块跑在上面那个最简环境内。
3. 可使用协程做到并发。编程语言使用 FP 范式的 COW 数据结构、immutable 以及纯函数等概念附加到协程里面实现模型内编程的可靠性。
4. 模块之间使用消息通信。通信机制由操作系统+编程语言提供。
5. 通信机制跨 CPU 核、NUMA 内存、CPU/GPU 甚至是由不同架构的网络机器，这些复杂的事情不应该由程序员来考虑。

【 在 milksea 的大作中提到: 】
: gc语言没什么可比性。go和c#当然不用考虑对象生存期的问题，但并发访问的安全问题不会被gc解决，所有权分析仍然是有力的工具。实际上，所有权分析的学术讨论远早于rust，很多论文都是基于java这种面向对象语言的。（例如，ownership type的重要综述是2013年的Ownership Types
: c++自由，rust限制多，其他方面差不了那么多。rust的卖点是安全又不是方便。大型企业大型项目就是需要更多语言约束，这个需求是很自然的。
--
修改:hgoldfish FROM 110.84.123.*
FROM 110.84.123.*