-
Notifications
You must be signed in to change notification settings - Fork 13.4k
Type ambiguity not reported when it may exist? #21878
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Comments
(Update:: but then again, explicitly instantiating |
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
} |
This is probably because of the implicit fallback for bottom variables to |
(from discussion with @nikomatsakis , this may have been injected by PR #17603 ) |
deciding what to do with this ticket is a 1.0 polish issue. (We would like to investigate consequences of removing the fallback to |
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:
I'm looking into it now. |
PR rust-lang#17603 introduced bottom type fallback but did it a bit too eagerly. This patch makes the fallback lazy so that `typeck` can run its cause and detect as many type errors as possible with regard to diverging types. Closes rust-lang#21878
Unassigning @nikomatsakis from ancient bug. |
Nominating for close. |
Agreed, no bug here. TL;DR inference fallback can be surprising. Also not so relevant with |
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()
ori32
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.
The text was updated successfully, but these errors were encountered: