Type ambiguity not reported when it may exist?

[alexcrichton]

trait Foo {}
impl Foo for () {}
impl Foo for i32 {}

struct Error;
impl Error {
    fn foo(&self) -> ! { loop {} }
}

fn bar<T: Foo>() -> Result<T, Error> { loop {} }

fn main() {
    // what type does `_` have? is it `()` or is it `i32`?
    let _ = bar().unwrap_or_else(|e| e.foo());
}

This code compiles, but I find it somewhat surprising as I have no type annotations on _ so the compiler shouldn't know what type it is (I presume it selects one of () or i32 perhaps).

This issue is motivated by docopt/docopt.rs#89 and isn't necessarily a bug per se, but it does seem somewhat surprising so I just want to make sure it is intended.

[alexcrichton]

cc @nikomatsakis

[pnkfelix]

(it seems like the compiler must be deducing the type is (), since removing that impl causes the compile to fail and removing the other causes it to succeed...)

(Update:: but then again, explicitly instantiating bar to i32 via bar::<i32> within main causes the compiler to choose i32 for the type. So, it seems like it is committing early on for some reason even though it should not be, AFAICT.)

[ftxqxd]

()-ness confirmed:

use std::default::Default;

trait Foo: Default { fn foo(); }
impl Foo for () { fn foo() { println!("()"); } }
impl Foo for i32 { fn foo() { println!("i32"); } }

struct Error;
impl Error {
    fn foo(&self) -> ! { loop {} }
}

fn bar<T: Foo>() -> Result<T, Error> { loop {} }

fn baz<T: Foo>(_: &T) { <T as Foo>::foo(); }

fn main() {
    let mut a = Default::default();
    |&mut:| a = bar().unwrap_or_else(|e| e.foo());
    baz(&a); // ()
}

Smaller case:

trait Foo { fn foo(&self) -> Self; }

fn foo<T: Foo>(x: T) -> T { x.foo() }

fn main() {
    // foo(x) and x.foo() should be equivalent, but aren’t

    // Bad:
    let _ = foo(loop {}); // error: the trait `Foo` is not implemented for the type `()`
    // Good:
    let _ = loop {}.foo(); // error: the type of this value must be known in this context
}

[nikomatsakis]

This is probably because of the implicit fallback for bottom variables to ().

[pnkfelix]

(from discussion with @nikomatsakis , this may have been injected by PR #17603 )

[pnkfelix]

deciding what to do with this ticket is a 1.0 polish issue. (We would like to investigate consequences of removing the fallback to (), in particular)

[edwardw]

It so happened that I fiddled with numeric and bot type fallbacks when trying to solve type inference issue for the new range expression. That branch reports the following error for the given testcase:

error: unable to infer enough type information about _; type annotations required [E0282]
let _ = bar().unwrap_or_else(|e| e.foo());

I'm looking into it now.

[brson]

Unassigning @nikomatsakis from ancient bug.

[brson]

Nominating for close.

[nikomatsakis]

Agreed, no bug here. TL;DR inference fallback can be surprising. Also not so relevant with !.