Regression in type inference from Iterator.sum

[untitaker]

The following used to work (around the time where AdditiveIterator still existed):

fn main() {
    let content = vec!["a","aa","aaa","aaaa"];
    let lens = content.iter().map(|x| x.len());
    println!("{}", lens.sum());
}

http://is.gd/2jQlp7

The error message:

<anon>:4:25: 4:30 error: unable to infer enough type information about `_`; type annotations required [E0282]
<anon>:4     println!("{}", lens.sum());
                                 ^~~~~

[steveklabnik]

/cc @nikomatsakis

[mitaa]

Iterator::sum and Iterator::product use defaulted type parameters, which are, I think, not yet implemented for functions. (RFC 0213 #21939)

[mitaa]

Testing with the shiny new Default Type Parameter Fallback:

#![feature(default_type_parameter_fallback)]
#![feature(iter_arith)]

fn main() {
    let a = [1, 2, 3, 4, 5];
    let it = a.iter();
    assert_eq!(it.sum(), 15);
}

test.rs:7:19: 7:24 error: the trait `core::ops::Add<&i32>` is not implemented for the type `<core::slice::Iter<'_, i32> as core::iter::Iterator>::Item` [E0277]
test.rs:7     assert_eq!(it.sum(), 15);

(example from the Iterator::sum documentation)

[untitaker]

@mitaa It appears that your example currently fails with the same exact message as OP: https://is.gd/eA5RJ0

[Mark-Simulacrum]

Nominating for compiler team discussion since this is a regression that slipped through a while back.

[Mark-Simulacrum]

Copying over #36201 to close that:

fn total1(a: &[u32]) -> u32 { // OK
    a.iter().sum()
}

fn total3(a: &[u32]) -> u32 { // Error
    a.iter().sum() + 5u32
}

fn f() -> f64 { // Ok
   0.0f64 +  vec![1.0f64].into_iter().sum::<f64>()
}

fn f2() -> f64 { // Error
   0.0f64 +  vec![1.0f64].into_iter().sum()
}

[nikomatsakis]

I believe this changed when sum() was stabilized -- it was rewritten to be generic over the sum type, which implies that it must be specified and cannot be inferred from context. Therefore, I think this is "not a bug" (nor, technically, a regression). I could be wrong though, maybe some details of our type inference changed -- if so, they seem likely to be bug fixes, though, since I think we are (correctly) refusing to guess types here.

[nikomatsakis]

I'm inclined to close myself.

[StefanoD]

@nikomatsakis
This is a good example, that you don't have to "guess" types:

fn total3(a: &[u32]) -> u32 { // Error
    a.iter().sum() + 5u32
}

Everything is u32. So why doesn't this work?

[jimblandy]

I'm having a hard time understanding why it's inappropriate to infer usize here:

fn main() {
    let v: Vec<usize> = vec![1,2,3,4];
    assert_eq!(v.iter().sum(), 10_usize);
}

Rust says:

rustc 1.19.0-nightly (5b13bff52 2017-05-23)
error[E0282]: type annotations needed
 --> <anon>:3:25
  |
3 |     assert_eq!(v.iter().sum(), 10_usize);
  |                         ^^^ cannot infer type for `S`

error: aborting due to previous error

The passive voice in "type annotations are needed" begs the question, "by whom???"