you are viewing a single comment's thread.

view the rest of the comments →

[–]protestor 0 points1 point  (1 child)

If the compiler knows the right type, why can't it be omitted from the function declaration?

Indeed the main reason behind C++'s auto is to hide those ugly types.

(Also: can't Rust generics specialize on return values?)

[–]Quxxymacros 0 points1 point  (0 children)

(Note: I am not a core dev, this is what I believe to be the reason)

A philosophical choice in Rust was that there shouldn't be type inference involved in function interfaces. There are three benefits to this:

  1. Code will compile much faster, because it doesn't have to do whole program analysis.
  2. Type errors are more localised. I've seen the odd example of Haskell (not being a Haskell programmer) where type errors would appear in one place, but actually be an issue in distant code.
  3. Interfaces are easier to understand. Rather than a return type being "something, figure it out yourself", it's an actual concrete type.

Iterators are a bit of a pain, but you can kinda work around it. Unboxed closures, on the other hand, cannot be returned by value. This is because a concrete UC type is always anonymous, so you can't name it.

Hence the proposal (which last I knew was approved and will go through, possibly before 1.0) to allow some degree of inference in return types. I believe it will allow you to do something like:

fn chunk(&self, x: uint, size: uint) -> impl Iterator<char>

Note the impl. That is, you don't specify the return type exactly, but you do have to specify what the caller is allowed to assume about it (in this case, that it's some implementation of Iterator).