Earlier quoted context omitted.
> Except where they can't, and those locations aren't terribly consistent. Why aren't they consistent? The Rust type inference is generally very good, and the places where you have to annotate are places where any typechecker would force you to annotate, because the types are simply underconstrained (e.g. the return type of Vec::collect or mem::transmute). > The Rust designers have publicly announced their preference…
> Why aren't they consistent? So, I went back to do a bit of research, and it's gotten better since this first bothered me, my apologies. My beef was with the `let x = vet::Vector::New:: ()` vs `let x: Vec = vec::Vec::New()`. Perhaps not the best way to word it, so consider this objection retracted. :) > the idea that we intentionally made the type inference less powerful than it could have been is totally false Exce…
That's an interface boundary, as I mentioned. You would have to write the types in many cases anyway for separate compilation to work. In languages where you have whole-program type inference like ML and Haskell, people frequently end up writing the types for functions because of this issue.
> Plus (and this is more related to the complete lack of implicit type conversions), there are types everywhere in the program. I frequently can't write a number without having to append a type, even when the type has been explicitly defined previously.
This has nothing to do with implicit type conversions, but is rather because numeric literals have no type. It is not a type inference problem; it is just the way that numeric literals are defined.
> let mut s: Vec3 = Vec3{x: 0f64, y: 0f64, z: 0f64, w: 0f64};
That much explicitness is not necessary. It could be written:
let mut s: Vec3 = Vec3 { x: 0.0, y: 0.0, z: 0.0, w: 0.0 };
let mut s = Vec3 { x: 0f64, y: 0.0, z: 0.0, w: 0.0 };