Type inference requires type of LHS to be known for binary operators

[mihneadb]

This is the code:

use std::hashmap;

fn main() {
    let mut map = hashmap::HashMap::new();

    let str = "Hello, world!";

    for &char in str.to_ascii().iter() {
        let count = map.find(&char);
        match count {
            Some(&x) => map.insert(char, x + 1),
            None => map.insert(char, 1)
        }
    }

    println!("{:?}", map);
}

Error message:

count_chars.rs:11:41: 11:42 error: the type of this value must be known in this context
count_chars.rs:11             Some(&x) => map.insert(char, x + 1),
                                                       ^
error: aborting due to previous error

[huonw]

Either

-            Some(&x) => map.insert(char, x + 1),
+            Some(&x) => map.insert(char, 1 + x),

or

-            Some(&x) => map.insert(char, x + 1),
-            None => map.insert(char, 1)
+            None => map.insert(char, 1),
+            Some(&x) => map.insert(char, x + 1),

makes the inference work:

• in the first case, the 1 in 1 + x defaults to int and so the second argument (i.e. x) is inferred to also be int
• in the second, the plain insert comes first and so that 1 there defaults to int and the inference succeeds.

(There are various ("correct") type errors and mutability issues that stop it compiling from after this.)

It seems like the original code should be legal, given the trivial adjustments (especially reordering the arms).

(cc @nikomatsakis)

[huonw]

Triage: I've updated the code for language changes; the inference is still suboptimal (i.e. it fails), the fixes in the comment above still address the inference issue, but also still hit the borrowing errors.

The following code works fine:

use std::hashmap;

fn main() {
    let mut map = hashmap::HashMap::new();

    let str = "Hello, world!";

    for &char in str.to_ascii().iter() {
        map.insert_or_update_with(char, 1, |_, v| *v += 1);
    }

    println!("{:?}", map);
}

[nikomatsakis]

Reading this example more closely, I actually don't think inference is expected to succeed here. You haven't told it the type of the values in the map, but you attempting to do x + 1. Due to the possibility of overloaded operators, we (at least currently) require that the type of x be known at that point. Reordering the arms makes type inference succeed because it forces the type of x to be int. Similarly, using insert_or_update_with also supplies the initial value (1), giving us the information we needed. I'm going to close.

[nikomatsakis]

That said -- we currently treat operator overloading as an operator, but it's possible that with the changes in #10337 we could avoid the requirement that we know the type of x. I'm going to tentatively re-open as a "sub-bug" of #10337.

[nikomatsakis]

Update title.

[Aatch]

Multidispatch should have fixed this, correct?

[nikomatsakis]

@Aatch It did not. The distinction has to do with needing to decide between "builtin" operators like + on integers and trait-driven operations. Currently we do this at the moment of type-checking the + (or other operator). It'll take some rearchitecting but we could defer this decision.

[arielb1]

This does compile (rather, type-check - of course it won't borrow-check) at 1.0 and above.