我个人理解，也不能处处都完全明确。编译器还是要聪明些，可以做些省略。

你觉得省略声明 更费脑子，那你可以写完整的声明。
有人觉得不写声明更简单，就可以省略声明。

另外，如果你写过rust的crate就会发现，为了通用性，会用到很多泛型，会导致一些类型非常复杂。但如果要求使用者也要都写出来，就很麻烦了。

比如：
let v = (0..10).collect();

要是完整写（这里还省略了Allocator）：

let v: Vec<i32> = <std::ops::Range<i32> as std::iter::Iterator>::collect(
    <std::ops::Range<i32> as std::iter::IntoIterator>::into_iter(0..10)
);

这也还是let的推导。如果match enum的时候也这么写，那就太恐怖了。



【 在 namoamituofo 的大作中提到: 】
: 你对如下观点有何见解：
: 我看类型推导也是个多余，属于过度设计。推导是写的时候省事了，但读的时候，读者脑子里面还得有个线程，人肉充当编译器进行类型推导。没感觉高明在哪，虽然如此，但也还有底线，还管类型，总比弱类型语言负责点。
:
--
FROM 115.220.224.*

为啥你说的话跟我想说的一模一样？
【 在 lvsoft 的大作中提到: 】
: 初学常有的状态。
: 上来先否定别人的设计，跟你之前学的别的语言一样那就是抄的，是缝合的。不一样那就是丑的，怪异的。
: nb你就自己发明一个语言，做到有大量用户。
: ...................
--
FROM 221.224.37.*

别搞笑
except是“除了”，意思都不对
onFailure，首先两个词就多余，大写F还特别丑陋，而且根本体现不出来“设计预期”。函数调用的返回被包装在result里，是设计阶段就构思好的、编译期编程的主动设计行为，并非无意识的运行时错误返回，怎么包装都是“程序员我”自己预期掌控的

【 在 namoamituofo 的大作中提到: 】
: io::stdin().read_line(&mut guess).expect("Failed to read line");
: 那你说说，这句读起来就像在期待失败，精妙在哪。改成onFailure或者干脆except，是不是更直观？
--
FROM 114.254.1.*

可以看出你是一个非常热爱技术的人，很羡慕你，能乐在其中。
我见过很多大神，怎么说呢，大神一定是聪明的，但不一定有品味，或者说一定没品味。因为他们已经满足于他们的聪明，不再追求品味了。想追求也求不得，因为编程语言就是挖土的铁锹，是干活的工具，本来就是丑的，不是用来审美的。
不管是一个工程的设计，还是一个语言的设计，过程中会出现大量的权衡行为。就是左右权衡，让一个丑的东西，到底是往左边丑一点，还是往右边丑一点，大神要根据产品的定位来做决策。最终弄出来一个凑合用的东西。


【 在 hellowub 的大作中提到: 】
: 学新语言的几种可能的状态：
: 1. 学到什么算什么，不动脑子。
: 2. 边学边跟之前的语言对比：
: ...................
--
FROM 60.247.21.*

你的意思是，我聪明但没品味？

哈哈

【 在 namoamituofo 的大作中提到: 】
: 可以看出你是一个非常热爱技术的人，很羡慕你，能乐在其中。
: 我见过很多大神，怎么说呢，大神一定是聪明的，但不一定有品味，或者说一定没品味。因为他们已经满足于他们的聪明，不再追求品味了。想追求也求不得，因为编程语言就是挖土的铁锹，是干活的工具，本来就是丑的，不是用来审美的。
: 不管是一个工程的设计，还是一个语言的设计，过程中会出现大量的权衡行为。就是左右权衡，让一个丑的东西，到底是往左边丑一点，还是往右边丑一点，大神要根据产品的定位来做决策。最终弄出来一个凑合用的东西。
: ...................
--
FROM 115.220.224.*