Closed
Description
struct Foo<'a> {
_s: &'a str
}
struct Bar<H: Handler> {
handler: H
}
trait Handler {
fn handle<'a>(&'a self, foo: Foo<'a>);
}
impl<F> Handler for F where F: Fn(Foo) {
fn handle<'a>(&'a self, foo: Foo<'a>) {
self(foo)
}
}
fn main() {
let foo = Foo { _s: "foo" };
let bar = Bar { handler: |_f /*: Foo*/| {} }; // uncomment to work
(bar.handler)(foo);
}
Gives:
error: type mismatch: the type `[closure test.rs:8:23: 20:6]` implements the trait `core::ops::Fn<(_, _)>`, but the trait `for<'r,'r,'r> core::ops::Fn<(hyper::server::request::Request
<'r, 'r>, hyper::server::response::Response<'r>)>` is required (expected concrete lifetime, found bound lifetime parameter ) [E0281]
Playpen: http://is.gd/E7sskd
Couldn't tell if this was #16473, @reem thinks it might be different. Either way, this hurts using hyper's server easily: Server::http(|req, res| {}).listen(8080)
.
Metadata
Metadata
Assignees
Labels
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Activity
reem commentedon Apr 22, 2015
cc @aturon @nikomatsakis do you think it would be feasible to fix this by the 1.0 release? It's a pretty unfortunate papercut for both iron and hyper.
I remember I recently helped @brson with this problem when he was using iron.
Ryman commentedon Apr 23, 2015
Very similar case based on nickel's usage of hyper:
Playpen: http://is.gd/OEkSd4
The fact that it works with a wrapping function means it's possible to get things done with convenience macros, which suggests the compiler is at least able to reason about this at some level.
brson commentedon Apr 23, 2015
Nominating because I hit this quickly trying to use Iron, the error was impenetrable and I had to ask for help.
bstrie commentedon Apr 23, 2015
Accidentally duped this bug, but not before coming up with a more minimal test case:
[-]Inference fails for closure[/-][+]Incomprehensible error message when inference fails for closure[/+]nikomatsakis commentedon Apr 23, 2015
I updated the title to reflect the fact that the error message is really bad here. It'd be nice to improve the inference, but in short term error message is priority.
pnkfelix commentedon Apr 23, 2015
P-high : provide better feedback in the error message to guide the user towards adding type annotations on the closure arguments.
Ryman commentedon Apr 23, 2015
@nikomatsakis Should I open another issue for the example I added? I don't know of any syntax available for type annotating the return type with lifetime requirements other than wrapping with a function?
28 remaining items