最近初学 rust 有个疑问

[monkeyWie]

rust 有空安全机制为什么不搞一套和 kotlin 和 dart 那样的空安全语法糖来替代手写 Option ，感觉写起来挺啰嗦的。

对比下：

• kotlin

// 声明可空
var number: Int? = null
// 取值，为空时给默认值
number ?: 0

• dart

// 声明可空
int? number = null;
// 取值，为空时给默认值
number ?? 0

• rust

// 声明可空
let number:Option<i32> = None;
// 取值，为空时给默认值
number.unwrap_or(0);

可以看到 kotlin 和 dart 有语法糖写起来舒服多了，rust 为啥不支持下，写成这样：

let number:i32? = None;
number ?? 0

当然还有更方便的链式调用，order?.user?.name 这种

[monkeyWie]

@mainjzb 这个味就对了啊

[PrivateRookie]

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

[PrivateRookie]

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

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

[blindinlights]

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

[agagega]

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

[GuuJiang]

首先，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 也挺真香的，到时候自然也不会想要什么?了

[ispinfx]

类型放个问题实在太恶心

[ispinfx]

号

[yueqianzhang]

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

[bianhui]

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

[monkeyWie]

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

[nebkad]

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

[lifespy]

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

[nebkad]

@lifespy

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

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

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

[caobug]

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

[IMXT]

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

[Venjer]

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

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

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