ren*_*yun 4 standard-library traits rust
在Read特征中,许多函数/方法采用buf: &mut XXXas(其中一个)参数并返回Result<usize>.例如,read_to_string()将其buf: &mut String作为参数之一并返回Result<usize>.
由于我来自许多语言,所谓的现代语言通常会返回read_string()函数调用的字符串.ReadRust类型中的特性设计让我震惊,因为它不返回字符串,而是将其作为参数传递(类似于C或其他更原始的语言).
我知道返回值(Result)用于指示读取是否成功,并且可以将其传递给match表达式.(我以前学过Lisp和Go,所以我不会质疑这种设计.)
为什么核心开发人员没有将这个特性设计为"将字符串与错误消息一起返回"？
例如,为什么不这样设计:
fn read(&mut self) -> Result<String> { ... }
该String还包含了长度,这样用户可以通过调用访问长度.len()在需要的时候.用户可以将其连接到String他希望的任何其他人,但关键点是在调用此函数之前不需要创建/拥有一个.
是否有任何特殊的理由来设计这种特性,就像现在这样？
ps我还在学习Rust(通过遵循Rust编程语言),并在阅读了大部分第一版后阅读第二版.如果上面的代码包含任何错误(特别是在处理生命周期时),请纠正我.
我不知道真正的原因,但有一些优点:
String分配方式.您可以从池中取出它,重复使用它等.read_to_string(或类似)调用中读取相同的字符串.没有必要连接字符串String可以是非空的),这就是为什么usize在Result签名
fn read_to_string(&mut self) -> Result<String> { ... }
如果来自更高级别的语言可能看起来更自然,但它无法控制String和分配.
RFC 517（IO 改革）指出（强调我的）：
该
read_to_end和read_to_string方法现在采取明确的缓冲区作为输入。这有多种好处：
表现。当知道读取将涉及大量字节时，可以提前预分配缓冲区。
“原子性”问题。对于
read_to_end，即使中间读取失败，也可以使用此 API 保留迄今为止收集的数据。对于read_to_string，情况并非如此，因为在这种情况下无法确保 UTF-8 有效性；但是如果需要中间结果，可以使用read_to_end并String在最后转换为 a 。
在 Rust 1.0 之前，确实返回了一个. 摆脱这一点是一个深思熟虑的决定。Reader::read_to_string String
甲read_and_create_string函数可以创建“上面”的Read::read_to_string，但相反的是不正确的。标准库中的代码需要非常灵活。