// 一个简单的例子
// 尝试从v中获取需要的几个元素，然后放进一个新的Vec中并return
// 可能并不存在这样的元素，如果不存在，我该返回空Vec还是None
// 两种api设计:
fn try_get(v: Vec) -> Vec
fn try_get(v: Vec) -> Option<Vec>
在stackoverflow有相同的问题，基本上是建议返回空列表而不是null，其中针对的都是c#/java之类的有null的语言，但是rust没有null，我该如何做？
1
共 4 条评论, 1 页
评论区
写评论还是看业务逻辑，比如说游戏里玩家获得了某种背包，那么就需要
Some<Vec<_>>，背包可以存在或不存在，存在的时候也可以为空；但同时，如果只有一种默认背包，背包必然存在，那就没必要Some来Some去了吧。 （只是举个例子，游戏里的背包一般没法只用一个Vec表示，还有容量大小物品限制等参数）try_xxx的返回值通常需要有个失败状态, 失败状态与成功但返回空在用户处理时可能是不一样的
例如:
read(&mut self) -> Result<Vec<u8>>,try_pop_batch(&self, n: usize) -> Result<Vec<T>>这些失败状态, 在用户处理时是特殊的, 可能会导致整个处理流程的结束, 因此与空Vec区分开比较好. 当然如果使用场景中, 失败与空对于用户处理是一样的, 那还是返回空会更简洁.
我又仔细想了一下： api-2中，所谓返回Option，是我们提前计算好Vec是否为空的情况，并用Option来表示并传递下去，None和空列表在逻辑上无法直接等同，同理，
Some和列表不为空也会对api使用者造成困惑，很可能会再次判断Some(v)中的v是否为空。总的来说，没有必要。--
👇
Bai-Jinlin: 铁2呀，灵活多变，假如真想在失败时获得空的vec可以直接unwrap or
铁2呀，灵活多变，假如真想在失败时获得空的vec可以直接unwrap or