最近初学 rust 有个疑问

因为 rust 是 MozillaML

rust 的 ? 运算符已经用于错误处理了, 像这样改会破坏现有的语义
https://blog.rust-lang.org/2016/11/10/Rust-1.13.html#the--operator

因为 Option 本来就是为了解决 nil/null 问题的

你返回也是 Option 就可以链式调用，或者用 try_block

我反倒觉得显式定义 Option 类型更加直观，类似的 Haskell 中也有 Maybe 类型

首先支持 #2

再说个可能的视角，Option 算是 FP 原生的 Monad 的概念吧，今天要是对 Option 这个 Monad 特殊处理了，那明天是不是要对 Result 也来个语法糖，后天再来个 Monad 是不是要再搞个语法糖，永无止尽

你可以自己加

@xtreme1 我懂你意思，但是语法糖可以换个符号嘛

Option ，Result 实现了 Try trait ，增加了新手很多的理解成本。让这个类型更“特殊”，对于编译器的语法分析，还是代码的阅读都毫无帮助。
kotlin ，dart 这么做很大程度上因为 null 是语言概念的一部分，而 Option 只是一个普通的类型，并无特殊的地方。

?这个问题有人认为简洁有人为奇怪什么东东。直接 option 包裹是最直白的

你以为的优势别人吐槽的也不少

因为 Option 远不只是?. ?:语法糖
举个例子，我可以为 Option 实现 Foldable ，可以 traverse 、sequence

@gitrebase Result 这个 Monad 已经被特殊处理了吧

```
fn main() {
let a = None;
println!("{}", a.unwrap_or(0));
}
```

这样也可以吧，可以自动推导出类型

因为 rust 有一个目标是直观无歧义， 方法重载都没有

说错了 默认值..

一个带多个问号的链式调用可能中间就中断了(虽然可以不这么写，但毕竟太灵活了没限制)
rust 相当于提醒你要处理调用链的异常情况，起码搜索的时候搜 unwrap 好搜，你搜问号试试...

还有可空类型本来是一个整体却要用两个分开的东西来表示感觉也怪怪的 (doge

https://fengliang.io/RustWHY/design_choices/why_not_overloading.html

问号不像一个严肃的系统编程语言用的，感觉风格不搭，Swift/Kotlin 这种风格用倒是挺符合

纯属抄 C++抄过头了。。。

先别管什么直不直白了
经常要输入的内容搞得太长了，我是嫌烦的

https://ziglang.org/documentation/master/#Optionals
动态语言可能没有说服力，让我们看一下号称代替 C 的 zig ，同样支持符号化 option 。

@mainjzb 这个味就对了啊

rust 的 Optional 是可以链式调用的啊, 而且 rust 一般都不怎么需要显示写类型, 直接类型推断就完事了, 你看这个例子里的变量赋值和 get_name 函数里的?用法
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=80b17634d331937a2565315bd9a4f84d

Option 作为普通类型的好处是可以方便地和 trait 结合, 比如这个例子就用 Into trait + Optional, 避免传参的时候多包一层 Some

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=56b2d9460341075d554afc8ca0ba0240

一般都不会标注类型的，自动推导就行了，没必要搞个特殊的语法

其实这个思路和 C++挺类似，就是加语法糖可以，但要想办法做得通用，得让用户自定义的类型也能用上。如果用问号代表 Option ，那就是一个定死的语法糖了。所以 Rust 里的问号是一个操作符，你可以实现 std::ops::Try 这个 trait 来自定义

首先，rust 的 Option 也是可以使用?运算符链式调用的，只不过由于?优先设计给了 Result ，所以只有当一个代码块里没有出现过将?应用于 Result 的返回时才可以应用于 Option ，否则只要有了一处 Result ，同一个代码块里在 Option 的地方用?就会报错，因为这时候期望的也是 Result ，只要满足了这个条件，对 Option 使用?是完全没有问题的，示例如下
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=a4973d87ed8e4d19934952ccb10ce6c6
上面所有认为 Option 没有?运算符并且还强行给出解释的未免有点先射箭再画靶了
不过话说回来，由于上面的限制条件的存在，并且现实中 Result 大量存在，所以能对 Option 用上?操作符的机会确实不多，因为不管 Result 还是 Option 的?，都是为了“像写命令式一样写 FP”这个目的而存在，等你习惯了 if let 解构以后就会发现其实 if let 也挺真香的，到时候自然也不会想要什么?了

类型放个问题实在太恶心

号

带问号的都有有 null/nil 概念，而 rs 变成了枚举的 case

没什么不可以的，可以啊。只是加了，又有人会说，为什么搞得像快餐语法一样，这会让一部分人心里少了优越感。众口难调，只是没有调对你的口罢了

@GuuJiang 那确实基本上用不了，只能用 and_then 来写了，好长一坨代码

? 语法糖仅仅用来表是可空真的是太浪费了

@nebkad #32 我觉得如果代码很多地方都要判断是否空，那就是值得的

@lifespy

如果你是说代码的很多 **表示类型** 的地方都需要表达是否可空，嫌弃 Option 字母多，那你需要的可能是编辑器自动提示。

如果你是说需要链式处理判断是否空，那也是我支持的语法糖作用，并且 Rust 也支持，你甚至还可以用 Try trait V2 来自定义衍生的语义。

总的来说，OP 对 rust 了解太少，习惯或者麻木的东西太多

太多 a?.b?.c 说明程序设计有问题，而且容易习惯用?取值。为避免歧义，我经常在 swift 中使用 a!.b 告诉阅读者这里不可能为空。

Rust 的 Option 就是从 OCaml 抄过来的。OCaml 里面就是 Option 。

糖多了就是容易滥用，rust 一把子掐断了，就是杜绝低级程序员的弱智行为。

kotlin 语法糖很多，很灵活，但是没多少人能写出正常的 kotlin 代码。尤其是从 Android 转过来的，java 写习惯了。写到 kotlin 一堆 ？ 。 写的人为了方便且避免 crash ，代码里一堆 a?.b?.c?.d?.e? 这种代码一旦出了问题。都不知道断在哪个 ？。如果强制用 Option, 方便和 避免 crash 不可兼得。为了方便，你只能 `a.unwrap().b.unwrap().` 强制 crash 。

或者挨个 match 嵌套处理。 这样就倒逼开发者自己去保证上游哪些值一定不能为空。这样写起来就方便了。