impl server::Handler for UserIndexHandler
impl UserIndexHandler
Which brings me to a question, how does implementing a trait prevent this code from compiling? Sorry for comparing apples to oranges again, but in Go implementing an interface is an invisible operation, that doesn't affect compilation. What's different with Rust?
The issue is, because this is a trait, you must conform to its signature. Which is here: https://hyper.rs/hyper/v0.10.0/hyper/server/trait.Handler.ht... and specifically https://hyper.rs/hyper/v0.10.0/hyper/server/trait.Handler.ht...
So yeah, my idea won't work, because those types conflict.
> Removing the trait impl was another thing recommended by the Arc guy at work, he didn't know how or why it worked.
I'm surprised it works on first glance, as I was assuming that you were implementing the trait for a reason, not just because. If you don't need the trait, then yeah, it's much easier.
> What's different with Rust?
See my StackExchange link elsewhere in the thread for a summary.
I'll maybe poke at this after my meetings, or maybe tomorrow. We'll see how amped I am for coding after all that ;)
Handlers aren't meant to be nested like this. That is, it's always going to break this way, because the handler needs to live as long as the request and response, so creating a sub-handler is not ever going to live long enough.
So yes, the solution is to not implement Handler for your UserIndexHandler; then you can just call it.
I bet there's something larger you could do as well, but I don't have enough experience with this interface to give good advice. Hyper's undergoing a huge docs drive for 0.11; I'm sure that'll help.
Yeah, it was removed literally last week, so it hasn't made it into a release yet.
Without knowing what version of postgres you're using, I can't _totally_ get this to compile, it complains that SslMode isn't there. But, I did fix your issue:
This compiles for me.The issue here is lifetime elision. http://rust-lang.github.io/book/ch10-03-lifetime-syntax.html...
Specifically, rule 3:
> If there are multiple input lifetime parameters, but one of them is &self or &mut self, then the lifetime of self is the lifetime assigned to all output lifetime parameters.
So here, Request and Response both have lifetime parameters. This means that your original signature is the same as
Which says "when I call handle, I borrow myself for as long as request and response are borrowed." That won't work; user_index_handler only lives for the duration of the call.The fixed signature says
"When I call handle, the request and response share one lifetime, and request also has another lifetime."You're no longer connecting &self to the request and response, and so things are just fine.
Honestly, this isn't the simplest signature; it's not surprising that you got stuck. This is also what people mean when they say "I fought with the borrow checker for a while, but then got over it", as it took me less time to fix this error than to write out this comment explaining how to! But until you've got that intuition and understanding, it can feel like hitting a brick wall.