fakeshadow

@w568w 你想说的应该是 ntex ，它是 actix 原作者写的新框架。写 xitca-web 的另有其人。

@bli22ard Rust 是系统级的语言，除了你说的应用场景还有其他的情况，例如:
1.没有原子变量的平台，例如某些嵌入式，他们没法使用 Arc
2.没有堆分配器的平台，这些平台和 1 类有些重合，他们不仅没法使用 Arc ，还无法使用任何依赖堆分配的智能指针。
3.不希望支付 Arc 开销的应用场景，比如单线程并发读写

如果标准库只是简单的套 Arc ，那么其 split API 对上面两个应用场景就是毫无价值的，他们还是要自己实现其常见的 split 方法，例如:
```
fn split(stream: &TcpStream) -> (ReadHalf<'_>, WriteHalf<'_> {
// 常用于栈上协程
}

fn split(stream: &Rc<TcpStream>) -> (ReadHalf, WriteHalf) {
// 常用于单线程
}
```

你说的应用场景是重要的，但 Rust 标准库的设计不能仅仅关注在某些重要领域而忽视其他的需求。这时候你反观标注库的实现，就会发现对内部可变的文件实现 Read, Write 是一个折中的方案，以上情况都可以简单的利用其满足自己的需求。你说它完美吗？那肯定不是，我相信也会有更好的实现方式。但在更好的设计被提出之前，我觉得标准库的实现是正确的。

讨论设计问题不要从你当前的需求出发，而是要把其他需求也考虑进去。比如你认为标准库应该提供 split ，那么它应该如何实现呢？

```
let (app_type , user_info) = {
let queries = Queries::from_uri(request.uri()).unwrap_or_default();
(AppTypeExt::get_from(&queries)?, UserInfo::get_from(&queries)?)
};

if let Some(app_type) = app_type {
request.extensions_mut().insert(app_type);
}

if let Some(user_info) = user_info {
request.extensions_mut().insert(user_info);
}
```

我觉得无所谓，我关注的是交流的对象，内容和目的。

酗酒的人没有生下来就如此的。所谓防微杜渐，一旦产生酒精依赖就需要认真对待。